[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:all-tabpanel ]

Jeff Mesnil updated WFWIP-189:
------------------------------
    Summary: Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies  (was: Operatoris not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies)


> 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)