Alec Merdler alecmerdler

TODO

Description

The OperatorGroups feature of OLM allows a single Operator to be installed into a single namespace and have its APIs provided to many other namespaces. To improve usability, the ClusterServiceVersion is "copied" into those target namespaces (but no Deployment is created). Adding a simple filter bar to the list view makes it easier to find "real" ClusterServiceVersion vs "copied" ones.

Screenshots

ClusterServiceVersion list view (filtered):

Description

Some Operators in the Marketplace do not support watching their custom resources at a cluster-wide level. OLM only ships with an OperatorGroup for cluster-wide Operators. Here we introduce a workflow for selecting a valid OperatorGroup for the given Operator package (based on installModes), and if one does not exist, creating a new one that satisfies the constraints.

Screenshots

Addresses https://jira.coreos.com/browse/ALM-894

Description

Adds status.conditions to the CatalogSource API. Only implements one condition: Available.

You Might Not Need a Custom UI

Red Hat has fully adopted the CoreOS vision of running applications by extending Kubernetes (rather than building on top using existing primitives). Operators use "provided APIs" (CRDs/apiservers) to give users a way to declaratively manage their apps. Now you can interact with your services and have the same experience as using the aws or gcloud command-line tool, because everything lives in the Kubernetes API. You have extended Kubernetes. The Operator Lifecycle Manager (OLM) is a comprehensive framework for resolving, installing, and upgrading these extensions in the same declarative way.

The OpenShift Console is a frontend for the Kubernetes API. Each list/detail view has an equivalent kubectl get (uses the raw REST endpoints). Naturally, the UI provides a lot of advantages over CLI: aggragating resources into a single view, hyperlinks to related views, cluster-aware autocompletion for YAML edi

Description

Improves insight into how the console is working under the hood by allowing users to see the equivalent API calls / kubectl commands that are active in the current view.

Description

Utilizing the Kubernetes API support for server-side dry run create/update in the YAML, we can perform more in-depth validation of objects before they are committed to the cluster.

Changes

Screenshots

Dry-run create (after clicking button):

	apiVersion: operators.coreos.com/v1alpha2
	kind: OperatorGroup
	metadata:
	name: global-operators

	# Built from https://github.com/operator-framework/operator-manifests/pull/8

	#! validate-crd: ./deploy/chart/templates/05-catalogsource.crd.yaml
	#! parse-kind: CatalogSource
	apiVersion: operators.coreos.com/v1alpha1
	kind: CatalogSource
	metadata:
	name: community-operators
	spec:
	sourceType: grpc

	document.querySelector('header').remove();
	document.querySelector('.pf-c-page__sidebar').style.position = 'unset';
	document.querySelector('.pf-c-page__main').style.top = '0';