[
https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin...
]
Brian Stansberry commented on WFCORE-433:
-----------------------------------------
As part of the application of the update to the Domain Controller, it rolls it out to all
registered hosts/servers in the domain, rolling the update back if there are failures.
The update request can include headers that let the user somewhat control the rollout,
both in regards to concurrency of updating servers and in regards to tolerance of failures
on individual servers (i.e. not rolling back.)
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)