[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ] James Strachan commented on WFCORE-433: --------------------------------------- Thanks [~bstansberry]. So a way to do a similar thing with Kubernetes using a git repo is : * use a gitRepo volume in the Replication Controller YAML file: http://kubernetes.io/v1.1/docs/user-guide/volumes.html#gitrepo so that each pod has a specific git revision (SHA) cloned at a specific folder. The WildFly container then just loads config from disk as usual. * when someone makes a change via the WildFly Admin Console a new git commit is done * update the git revision in the Replication Controller and do a 'Rolling Update' in Kubernetes like this example https://github.com/fabric8io/kubernetes-client/blob/2e79032968bb2dfc299dc... only you'd be updating the spec.template.container's git volume rather than the image * this basically then creates a new Replication Controller for the new git revision and starts spinning up new containers with the new configuration; as each one starts, is running and is 'ready' (using Readiness Probes to know if the WildFly container is up and running - e.g. is it listening on all the ports, is it ready to receive HTTP requests and whatnot) http://kubernetes.io/v1.1/docs/user-guide/production-pods.html#liveness-a... - when the container is ready then it takes part in the Kubernetes services for load balancing. Then when its ready, the old RC is scaled down; so that 1 container rolls over from the old to the new configuration. * the process running the rolling upgrade can monitor the newly created pods and check they startup OK; if they don't it can rollback the change and if need be rollback the git revision (or you can use branches if you want, kinda "Pull Request" stylee that changes only get merged to master after the rolling upgrade succeeds?) You could run the above in the wildfly container that gets the git commit change from the Admin Console; though it might be better to elect a leader using Kubernetes' leadership election and letting that container watch for changes in git and perform the above steps. You already have code to do dynamic updates of configuration on the fly to WildFly containers; you could keep doing that if you like - though its kinda easier to just adopt the immutable container model as there's less chance of incremental change bugs; plus you can the reuse the 'rolling upgrade' mechanism to do more than just deal with config changes - e.g. for testing out rolling upgrades of new docker images of wildfly too. BTW you might want to look at using Kubernetes lifecycle hooks to ensure that containers are sufficiently drained before they are stopped. e.g. http://kubernetes.io/v1.1/docs/user-guide/production-pods.html#lifecycle-... - then you can make kubernetes wait for the containers to have completed processing requests before it shuts down etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)