Configuration's on operator deployment

[sina-grz]

I have been considering and evaluating OLM implementation in our infrastructure (self-hosted, vanilla Kubernetes, GitOps + Argo CD + Terraform) for installing and managing operators.

One major concern is the migration process from Helm-managed operators, particularly regarding configuration.

In the Helm approach, the unwritten rule is to use templating and variables as much as necessary to provide a configuration standard/interface for users in the values.yaml file. Another best practice is to include comments and documentation inside values.yaml.

For example, this could include the number of replicas an operator can have, the Deployment spec in general, and, separately, the operator's logical configuration, which might be templated as pod environment variables, ConfigMaps, Secrets, or whatever mechanism the operator authors have designed to accept configuration .

Putting these configurations in a values file helps a lot in a GitOps approach, rather than creating the operator bundle manifests in Git and then importing or adding separate configuration manifests to Git.

So, in my opinion, the configuration API in ClusterExtension would raise two questions:

Do people actually practice writing configurable bundles?

Is there an out-of-the-box method, interface, or API to inspect and validate the configuration schema that a bundle provides?

[joelanford]

@sina-grz Thank you for raising this discussion! As of today, operator-controller does not support author-defined configuration in bundles. The only bundle format that operator-controller currently supports is the registry+v1 bundle format that the original OLM (v0) defined.

However, we are keenly aware of the limitations of that format and we are planning to introduce support for (some) helm charts, hopefully in the near future. The ClusterExtension Config API was specifically designed to be able to handle new formats that can provide their own configuration schema, embedded in the bundle itself.

When we introduce helm chart support in OLMv1, the cluster admin will be able to provide their Helm values in this field, and OLMv1 will even perform validation of those values against the chart's values.schema.json if it is provided.

Do people actually practice writing configurable bundles?

As of today, no. Because it isn't possible with registry+v1. However, based on feedback we've received, there is quite a bit of demand from operator authors to be able to define their own configuration schema based on specific feedback they are getting from their users.

Is there an out-of-the-box method, interface, or API to inspect and validate the configuration schema that a bundle provides?

A registry+v1 bundle "provides" a fixed schema (based on OLMv0's Subscription.spec.config API). Helm charts obviously deliver their own arbitrary schema. In OLM's initial support for Helm charts, I anticipate this schema being unknown to OLM until it unpacks the chart and attempts to apply the ClusterExtension configuration to it.

However, this is a question that has come up before as it is a clear UX concern for the schema to lack discoverability. Over time, I would expect to improve bundle schema discoverability. But we have not deeply discussed any designs in that area yet.