[jboss-jira] [JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
[
https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin....
]
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-configm... 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/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)