[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ] 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 -- This message was sent by Atlassian JIRA (v6.4.11#64026)