Control ConfigMap change while update from ClusterServiceVersion

[dmvolod]

Feature Request

Is your feature request related to a problem? Please describe.
Now ClusterServiceVersion configuration supports a ConfigMap creation/update which allows operators to bring and store some peace of configurations and parameters outside the code and possibility to update some parameters without code change.

operator-lifecycle-manager/pkg/controller/operators/catalog/operator.go

Line 1849 in fbbb1ed

case configMapKind:

If ConfigMap just stores internal operator configuration only, there is no problem for current implementation.

But in some cases operator configuration could combines standard parameters and user configured parameters which can be stored inside a single ConfigMap configured via ClusterServiceVersion, i.e. contain application.property.key.default key in Data and customer can create a new key with following name application.property.key.custom which will override default value. In this case, every operator update via OLM will override whole ConfigMap and remove all customer related keys and values.

Would be nice to have an out-of-the-box solution for this functionality, i.e. ConfigMap update should keep all key-value combinations that's not present inside ClusterServiceVersion ConfigMap configuration and just update preset operator parameters.

Describe the solution you'd like
Use a Web-hooks to control this behavior can be an option, but need an additional code to be implemented.
For example kubectl apply -f implements the same functionality, keys and values which are absence in the file but present inside k8s ConfigMap never deletes. In this case a tow way merge (keep not present in updated ConfigMap keys and update just presents) should be used for ConfigMap or we can control update options with standard (whole replace and update) or just incremental depends of the customer setup.

[njhale]

Hi @dmvolod, thanks for taking the time to post!

Now ClusterServiceVersion configuration supports a ConfigMap creation/update

CSVs don't have any features that allow for the creation of ConfigMaps. From your link, it looks like you're talking about using an operator bundle to supply ConfigMaps, so I'm going to continue with that interpretation.

Would be nice to have an out-of-the-box solution for this functionality, i.e. ConfigMap update should keep all key-value combinations that's not present inside ClusterServiceVersion ConfigMap configuration and just update preset operator parameters.

Unfortunately we don't have a way to know if the merge we'd be performing always results in a valid configuration. Consider what happens when the data in this ConfigMap is structured in some way and that structure changes between releases of an operator.

Use a Web-hooks to control this behavior can be an option, but need an additional code to be implemented.

Operator authors can supply webhooks in their bundles today, but there is added complication in having a webhook affect the application of the bundle itself; i.e. we would need to make sure it's up and running before the bundle is applied, which becomes a "chicken and egg" problem.

IMO, operator configuration really belongs to the domain of the operator itself and is not something we can implement generically in OLM without being very opinionated about how operators work. Following this reasoning, an operator would create, manage, and upgrade their configuration themselves.

I'm going to close this out for now. If I've misinterpreted anything or you have a more detailed proposal for how we could do this generically, please feel free to reopen.