[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=13167204#comment-13167204 ] 

James Strachan edited comment on WFCORE-433 at 2/23/16 12:29 PM:
-----------------------------------------------------------------

Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual step to roll the 3 containers forward to the new configuration?

When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).

Typically that just means bouncing the pods in kubernetes. One exception could be in git repos; 
http://kubernetes.io/v1.1/docs/user-guide/volumes.html#gitrepo

you can use a gitRepo volume in Kubernetes which you could fix at a specific revision; you could then use a Kubernetes Rolling Update to change the RC configuration to refer to the new git commit to make changes:
http://kubernetes.io/v1.1/docs/user-guide/update-demo/README.html

that gives you full control then of when you move forward to a new configuration change; or backwards again. 


was (Author: jastrachan):
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual step to roll the 3 containers forward to the new configuration?

When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).

> 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)