[jboss-jira] [JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies

[Jeff Mesnil (Jira)]

    [ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792396#comment-13792396 ] 

Jeff Mesnil commented on WFWIP-189:
-----------------------------------

This problem is not specific to the operator and is something inherent to Kubernetes.

There are various approaches to mitigate this issue and they all seem ad hoc...
The solution mentioned in https://blog.questionable.services/article/kubernetes-deployments-configmap-change/ is not sufficient. It requires to watch for any config map / secrets that the application references and compute their checksum and put that info in the WildFlyServer resources. This goes beyond what the operator should deal with (and still leaves some windows that would result in inconsistencies between pods).

As far as I can tell the best way to mitigate that issue is to "version" the names of the config maps referenced by the operator.

Eg.

{code}
spec:
  envFrom:
   - configMapRef:
      name: my-config-1
{code}

If a change must be made to the config map, it can be copied to another config map named config-2.
Then the WildFlyServer Spec can be updated with that info:

{code}
spec:
  envFrom:
   - configMapRef:
      name: my-config-2
{code}

I don't think the operator should change the semantic and behaviour of the existing Kubernetes resources. it should comply with it and works in a way that is consistent with Kubernetes. It is known that updating a config map will not trigger a rollout of a deployment (even more so any change in a statefulset).




> Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFWIP-189
>                 URL: https://issues.jboss.org/browse/WFWIP-189
>             Project: WildFly WIP
>          Issue Type: Bug
>          Components: OpenShift
>            Reporter: Petr Kremensky
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>              Labels: operator
>
> User is able to share environment variables in a ConfigMap or Secret and pass it to Operator via [WildFlyServerSpec#envFrom|https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wildflyserverspec] field. Problem is, that Operator is not aware of changes in Secret/ConfigMap (only reference change is recognized - add or remove ConfigMap/Secret reference). This could lead to inconsistency of environment between pods in a single project (moreover this could lead also to inconsistency between projects in case that ConfigMap/Secret is shared by them).
> The reaction on ConfigMap/Secret content should be doable, see https://blog.questionable.services/article/kubernetes-deployments-configmap-change/
> *reproduce*
>  * create a config map with ("foo1", "bar1") entry
>  * create an operator (size = 1) with a reference to the config map
>  * update the config map - add ("foo2", "bar2") entry
>  * resize the operator
> *actual*
> {code}
> $ oc get pods
> NAME                                READY   STATUS    RESTARTS   AGE
> eap-cd-0                            1/1     Running   0          112s
> eap-cd-1                            1/1     Running   0          94s
> wildfly-operator-55b544c4bb-wts8l   1/1     Running   0          2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *expected*
> {code}
> $ oc get pods
> NAME                                READY   STATUS    RESTARTS   AGE
> eap-cd-0                            1/1     Running   0          112s
> eap-cd-1                            1/1     Running   0          94s
> wildfly-operator-55b544c4bb-wts8l   1/1     Running   0          2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *Environment:*
> *operator version:* [467407a|https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9a4c7b6ab6bcc896e49]
> *openshift version:*
> {noformat}
> OpenShift version: 4.1.11
> Kubernetes Master Version: v1.13.4+df9cebc
> {noformat}
> Out of curiosity, is there is way to rollout the pods manually as {{oc rollout}} was designed for DeploymentConfigs and cannot be used here?



--
This message was sent by Atlassian Jira
(v7.13.8#713008)