ConfigMap changes do not persist when using the operator

[RickJWagner]

Describe the bug

Making a change to the ConfigMap 'che' does not result in a lasting change. A few minutes after changing some value from 'x' to 'y', the change will revert and 'x' will again be seen in the ConfigMap.

Che version

6.x

Steps to reproduce

Use Che (or CRW) on OpenShift. Using the OpenShift console, try to edit the ConfigMap 'che'. Change some value, say 'nonProxyHosts'. A few minutes later, open the ConfigMap again-- the changes will be lost.

Expected behavior

The ConfigMap should maintain the value, and in an ideal situation it will be propagated to new copies of the affected components.

Runtime

OpenShift 3.11

Screenshots

N/A

Installation method

Via Script, per CRW documentation.

Environment

Red Hat OpenShift 3.11 lab cluster

Additional context

There is a workaround:

• Make a copy of ConfigMap 'che'.
• Change the copy as desired. In my case, this was changing nonProxyHosts
• Update the 'codeready' Deployment to point to the new

[RickJWagner]

Please assign to @davidfestal

[RickJWagner]

Related CRW issue:
https://issues.jboss.org/browse/CRW-339

[skabashnyuk]

@RickJWagner I may assume that such behavior is the fundamental behavior of the operator. Instead of editing ConfigMap I think you should edit CR that che-operator will read and make appropriate changes in ConfigMap. @davidfestal @benoitf am I right?

[davidfestal]

Let me make things clear:

@skabashnyuk is right: the che config map is expected to contain values that are derived from the CheCluster custom resource fields. Thus it is expected that is would always be kept in sync with the CR.

However, for other Che settings which are not driven by the CheCluster custom resource, a custom config map is provided, that can be changed / filled at will without being overridden or synced by the Che operator.

As for the Che redeployment, the rules are the following:

• If some change in the CheCluster Custom Resource brings a change in the synced che config map, then the che POD will be restarted automatically as a consequence, and will take the new values of the che config map into account.
• However manual changes in the custom config map do not automatically trigger a restart of the che POD. So you would have to restart the Che POD manually to have the new values of the custom config map taken in account.

[slemeur]

Does it clarify and help @RickJWagner ?

[RickJWagner]

Hello @skabashnyuk , @davidfestal , @slemeur
Thank you for these helpful posts, they are useful.
I now understand an important issue: Not all Config Maps will hold changes. (Some allow edits, and the edits persist. Others, like 'che' do not.)
For posterity's sake (soon to go into our knowledge base), here is the way to bring a change from CheCluster to the running Pods:

1. Change CheCluster 'codeready'. This can be done in the OpenShift console
2. Delete Config Map 'che'. It will be automatically recreated, with the new value from Che Cluster 'codeready' in place.
3. Delete the Pod, i.e. Che Server. It will be recreated using values from Config Map che. The value will be the one derived from Che Cluster 'codeready'.
   Thanks again for the help in understanding this.

[slemeur]

Thanks @RickJWagner !

[davidfestal]

@RickJWagner let me precise 2 points:

• Change CheCluster 'codeready'. This can be done in the OpenShift console

• Delete Config Map 'che'. It will be automatically recreated, with the new value from Che Cluster 'codeready' in place.

che config map doesn't even need to be deleted: if you changed some CheCluster field that drive some value in the che config map, the operator should change the che config map accordingly, and changes to the che config map should trigger a restart of the che pod.

• Delete the Pod, i.e. Che Server. It will be recreated using values from Config Map che. The value will be the one derived from Che Cluster 'codeready'.

changes done by the operator to the che config map should trigger a restart of the che pod automatically.
However when doing manual changes to the custom config map, the Che POD should be restarted manually by deleting it.

[nickboldt]

I've resolved downstream issue https://issues.jboss.org/browse/CRW-336

And I've opened https://issues.jboss.org/browse/RHDEVDOCS-1248 to improve doc about this feature-not-a-bug. :)

[MichalMaler]

I created a concept module for this topic. Please, let me know if you would add something to it.
https://docs.google.com/document/d/1eMRB_FDgEqzVzCBKOdhjA1eypw-Fl6bljuDrnRepBHk/edit