geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Sun, 15 May 2005 21:17:46 GMT
Phil Steitz wrote:
> Aaron Mulder wrote:
> <snip/>
> 
>>
>>     Also, wearing my end user hat, I'm not as concerned about this
>> issue as stated -- Every time I upgrade, for example, JBoss, I install it
>> into a new directory, reapply any configuration changes, and redeploy my
>> apps.  It might be different if the product offered an "upgrade in place"
>> install option.  Still, I upgrade pretty rarely.  So an easy upgrade 
>> path is probably for me, at best, a "nice to have".
>>
>>     I'm more concerned about the inability to conveniently edit 
>> serialized configuration information, which I hope to take up on the 
>> other thread that Jeremy was going to start.  That is a lot more of a 
>> common issue for me -- more of a "must have".
>>
>> Aaron
> 
> 
> As a user, I pretty much agree with Aaron (both points), with the 
> following additional comment on the first one:
> 
> Major version upgrades are relatively rare events, but applying patches 
> / service packs / whatever they may be called is more common and 
> sometimes needs to be done quickly with minimal disruption.  Having to 
> redeploy all apps on a server to which a patch is applied is not ideal. 
> Having strange things happen after patches are applied is even less fun ;-)
> 
> So I guess it all depends on what exactly we mean by "upgrade"...
> 

I put my thoughts on the wiki:
http://wiki.apache.org/geronimo/Architecture/ConfigurationManagement

My expectation is that if the original server and a "patched" server can 
both provide the environment the application expects then it will run 
identically on both systems.

I would expect the change process to be something like:
* get patched version of server bundle from somewhere
* install the patched bundle in a test server
* check the existing application still runs and the problem is fixed
* build a new application bundle depending on the patched server version

you then have a couple of choices for rollout, either
* push patched server bundle to production
* pro-actively push to runtime servers, replacing the buggy server

or
* push patched server bundle to production
* push updated application bundle to production
* roll new application bundle to runtime servers as appropriate
* each runtime server will get the patched server bundle from
   config control so that it can support the new application version

and other variations of either approach.

--
Jeremy


Mime
View raw message