[jboss-jira] [JBoss JIRA] (WFCORE-2994) Using git for managing configuration history

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2994:
-------------------------------------
    Description: 
Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to support using git to manage the persistence of the configuration and its history.

Example use cases this would make possible:
* We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
* It is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
* git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration. _(Note that using this feature in any of these ways in the WildFly/EAP cloud images is not part of this RFE. The intent here is just to illustrate possibilities. There are many other factors that go into deciding how WildFly/EAP should work on the cloud.)_
*  We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
* With branches administrators could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.




  was:
Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to use git to manage the persistence of the configuration and its history.
* We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
* it is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
* git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration
*  We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
* With branches we could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.






> Using git for managing configuration history
> --------------------------------------------
>
>                 Key: WFCORE-2994
>                 URL: https://issues.jboss.org/browse/WFCORE-2994
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 3.0.0.Beta26
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to support using git to manage the persistence of the configuration and its history.
> Example use cases this would make possible:
> * We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
> * It is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
> * git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration. _(Note that using this feature in any of these ways in the WildFly/EAP cloud images is not part of this RFE. The intent here is just to illustrate possibilities. There are many other factors that go into deciding how WildFly/EAP should work on the cloud.)_
> *  We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
> * With branches administrators could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)