[
https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin....
]
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/blo...]
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-configm...
*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/467407a6c21102...]
*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)