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

[Petr Kremensky (Jira)]

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

Petr Kremensky commented on WFWIP-189:
--------------------------------------

Thanks for looking into this, even community seem to be split regarding the "versioning" of the config maps and secrets (https://github.com/kubernetes/kubernetes/issues/22368), I agree it's not clever to go against the whole world here, let us be consistent with Kubernetes, at least for now. If some enhancements are requested by customers on this, EAP7 jira should be created and properly prioritized by PM.

I'll close this one, add the proposed way of using the config maps and secrets into our testsuite and create a JBEAP documentation jira to make sure this will be part of our documentation.

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