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

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero commented on WFCORE-433:
----------------------------------------

{quote}storing diffs as CLI scripts sounds awesome as long as console can generate them and duplication of changes is removed. e.g. first set listen port to 445 and then change to 443. The first rule is then useless as it will be overridden by the second.{quote}
Good point that would be interesting, but in fairness even _git_ would still keep the full history with all duplication. It might even be convenient for auditing reasons to know that person X changed the port to 445 at some point in time, and then someone else changed it to 443 at a second time. The "commit message" would be a nice to have too, so git seems a good fit even if it was just to store an append-only sequence of CLI scripts.

+1 for {quote}human readable diff-like approach{quote}

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