TODO
apiVersion: operators.coreos.com/v1alpha2 | |
kind: OperatorGroup | |
metadata: | |
name: global-operators |
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.
ClusterServiceVersion
list view (filtered):
# 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 |
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.
Addresses https://jira.coreos.com/browse/ALM-894
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
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.
Dry-run create (after clicking button):
document.querySelector('header').remove(); | |
document.querySelector('.pf-c-page__sidebar').style.position = 'unset'; | |
document.querySelector('.pf-c-page__main').style.top = '0'; |