Versioning of Deployment

[dimitris]

(First posting in this forum :)
This is related to:
http://www.jboss.org/wiki/Wiki.jsp?page=DeploymentService
A simple way to version the deployments would be to extend the deployment service. Assuming we have a setup like:
./deploy
./undeploy
we could add:
./store
Then DeploymentService would have a new method called
saveAsVersion(String id) that would deep copy the first two directories to e.g. ./store/v1.0.

A method restoreVersion(String id) would then clear the content of the versioned dirs and copy back the specified version.

There are obviously issues with how we handle data, or what we do with libraries in server/xxx/lib, that can only reloaded after a server restart.

[ccrouch]

Having done a quick review of what WegLogic 9Beta, WebSphere 6.0 and Tomcat 5.0 do in this area I'm feeling less enthusiastic about implementing a sophisticated versioning scheme for the first phase of the Admin Console.

All the application servers listed above provide the ability to make changes through their respective admin consoles and then in a separate step actual commit/rollback those changes so they are picked up by the running server, or picked up the next time it restarts. All three maintain these "cached" configuration changes across user sessions of their admin consoles, so you can logout/walk away and the changes you've made are still available when you log back in. Some differences do exist between the implementations:

-WebLogic gives you a nice panel which lists the individual changes you've made. But scarily also lists some attributes I didn't change (it is still beta though). From this panel you can "Activate" the changes or roll them back.
-Websphere in its panel just lists the xml files you are about to update, which really isn't very informative since a few xml files hold all the configuration. Similarly to WebLogic you can then "Save" or rollback your changes. Helpfully it does offer up a reminder of the changes when you attempt to logout.
-Tomcat just has a "Commit" button and gives no indication of the change you, or anyone else did. Also the only option for rolling back changes would be appear to be restarting the Tomcat instance.

Initially I think we should be looking at how best to maintain the configuration cache, rather than a full blown versioning mechanism. I think making it the responsibility of the DeploymentService would be a good idea, since it is then not impacted by any change in the web-tier. Initially I think that it is okay for all Admin Console users to share the same cache, so one would see/be warned about changes others are intending to make.

Thanks

[rauschuber]

I agree with producing something useful yet with as few cool features as possible in the first go-round. Versioning will be very useful, but it doesn't have to be in the product for it to work.

[ccrouch]

"rauschuber" wrote:
I agree with producing something useful yet with as few cool features as possible in the first go-round. Versioning will be very useful, but it doesn't have to be in the product for it to work.

Right. I think commit/rollback should be sufficient.

Thinking more on where the "cached configuration" should live, may be it makes more sense to give the Admin Console its own persistent store. I think this would be invaluable when dealing with a multi-node setup. You don't want to have to go to each node in the cluster to retrieve cached configuration information. Much better to keep it close to the Admin Console and then push the changes out to each node on commit.

[ccrouch]

Here is an option for how the commit/rollback might work in the web-tier:

1) After a change is made through the Admin Console a new menu/navigation item appears which says "Pending Changes".
2) Clicking on this item will take you to a page that says "You have pending changes to the JBoss server" and has three buttons:
2a) "Commit" button: pressing this sends all the cached configuration changes to the DeploymentService. The user is returned to the "Home" page with a message that the changes were successfully/unsuccessfully applied. The "Pending Changes" menu item disappears.
2b) "Roll back" button: pressing this discards the cached configuration changes. The user is returned to the "Home" page with a message that the changes were discarded. The "Pending Changes" menu item disappears.
2c) "Cancel" button: pressing this the user is returned to the "Home" page. The "Pending Changes" menu item remains.

Thanks