[jboss-jira] [JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally

[Ken Wills (Jira)]

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

Ken Wills commented on WFWIP-167:
---------------------------------

As I recall in the past, the problem with using a ConfigMap for standalone.xml was that as configmaps are unversioned, a change could be made that invalidates the config and not have a way to roll back. I haven't looked closely at the plan for the operatior, but having the operator manage the available versions would potentially avoid this concern and allow rollback etc. (The spec supports a specific name, so this could include a version.)

WRT to restarts, a simple approach would be to configure EAP to have a deployment trigger on the ConfigMap (which I think is supported, thought I'm not 100% sure) -- but in any case the operator is in a position to handle the deployment strategy.

[~mchoma] FWIW, the kubectl / oc tools may be an appropriate way to manage an external update of the standalone.xml in the ConfigMap, that would be a more appropriate way of fetching and importing the content from whatever source (URL, local file) the user would like to use.

> 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#standaloneconfigmapspec



--
This message was sent by Atlassian Jira
(v7.12.1#712002)