[
https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin....
]
Martin Choma commented on WFWIP-167:
------------------------------------
Isn't this externalizing configuration denying infrastucture immutability concept?
So far we have overriding feature in s2i [1], but that keep infrastructure immutability
pattern. But current Operator does not have s2i support.
Also note as there will be only one Operator at a time, we cant remove
StandaloneConfigMapSpec, when s2i will be part of operator. So now question is is it worth
adding it in current state?
[1]
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
EAP Operator handling ConfigMap internally
------------------------------------------
Key: WFWIP-167
URL:
https://issues.jboss.org/browse/WFWIP-167
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Choma
Assignee: Jeff Mesnil
Priority: Major
If I understand description in [1] correctly. To specify custom standalone.xml I have to
create ConfigMap with standalone.xml first and afterwards link operator to this
ConfigMap.
Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally
I just specify file URI where custom standalone.xml is located. This location have to be
accessible from operator pod. In this way we can look at it as hiding internals
(implementation details) from users.
Currently when user wants to change standalone.xml he does in ConfigMap, not operator.
When changing standalone.xml through config map, I assume pod have to be restarted
manually. Operator could do that for me.
However this can be triggered by storing newer version of standalone.xml under another
key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator.
What do you think? Have you considered this approach?
[1]
https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)