[jboss-jira] [JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly

[James Strachan (JIRA)]

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

James Strachan commented on WFCORE-433:
---------------------------------------

The original motivation for this issue was to be able to provision WildFly containers using a shared configuration in a git repo; such as if being used with fabric8 version 1.x - so that changes to the configuration are stored in a shared space which on change can be replicated to many containers. 

Actually now Kubernetes has introduced ConfigMap, so a better Cloud First approach for WildFly when using Kubernetes / OpenShift / Atomic / Fabric8 version 2.x would be for it to store all configuration files inside a ConfigMap:
https://github.com/eBay/Kubernetes/blob/master/docs/proposals/configmap.md

then each WildFly docker container would mount each ConfigMap entry (e.g. one for “standalone.xml" or whatever files WildFly needs for its config) as a volume (file) on the file system; then WildFly would watch the file as usual to detect changes and reload etc. 

But when the file is changed via the Admin Console, rather than writing directly to the file system, we’d write to the ConfigMap REST API. 

e.g. if you have a cluster of 5 containers and you want to add, say, a DataSource; writing to the single ConfigMap resource inside Kubernetes would then automatically update the standalone.xml on each of the 5 wildfly containers.

So the only real change thats required is that whenever standalone.xml is about to be written, its not written to the local file system, instead we GET the ConfigMap resource from the kubernetes REST API, then update the ‘standalone.xml” entry in that object, then POST the change back to the ConfigMap.

This would provide “Domain Controller” like behaviour for configuration of a cluster of WildFly containers while just relying on standard kubernetes semantics

> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
>                 Key: WFCORE-433
>                 URL: https://issues.jboss.org/browse/WFCORE-433
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: James Strachan
>            Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)