You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
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?
All reactions