OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sdd] [requirements] use case for 2.1.6.1: sidegrade (side install)


Question inline...
 

> -----Original Message-----
> From: James Falkner [mailto:james.falkner@sun.com] 
> Sent: Wednesday, February 22, 2006 6:03 PM
> To: sdd@lists.oasis-open.org
> Subject: [sdd] [requirements] use case for 2.1.6.1: sidegrade 
> (side install)
> 
> Specific problems of supporting in-place upgrades:
> 
> By only supporting in-place upgrades, ISVs must deliver 
> complex solutions to enable customers to enable customers to 
> update/upgrade in place without having to force customers to 
> allocation additional systems for update/upgrade purposes. 
> The matrix of version combinations required to be tested and 
> supported can quickly become extremely complex.  It is costly 
> for ISVs to be able to certify that many of these 
> combinations of component versions will work properly.  The 
> pervasive support results in complex and error prone 
> technical solutions which often result in corrupted in-place 
> installations, forcing a removal/reinstall.
> 
> Specific use case of sidegrade:
> 
> Customer is running particular customized version of 
> software, including custom data that was created after the 
> initial install, and custom configuration tuned for their 
> environment.  This is running either in a production 
> environment or development environment, with high 
> availability requirements (i.e. can't be taken down except 
> during scheduled maintenance periods).


[John Patton]
Would this not be met with requirement 2.4?  The user can decide if they
want to install the new version in a sidegrade fashion by installing it
as a second instance?

 
> Customer obtains latest version of software, and would like 
> to upgrade to that version, with the ability to revert to the 
> old version if the new version does not operate as expected.
> 
> Customer installs the new version in a sandbox-type environment (i.e.
> different directories/folders, different port numbers, etc) 
> and must now migrate user data and configuration from old to 
> new version.  Customer then tests that the new version works 
> as expected, in this sandbox environment.  If it does not, 
> the current version continues to operate.
> If it does, customer selects a convenient time to switch to 
> the new version, by disabling the old version, changing the 
> new version to use the standard external port numbers or 
> other end user interfaces, and finally uninstalls the old 
> version.  This is a sidegrade.
> 
> Basically, supporting sidegrades are to 1) reduce the testing 
> burden by only requiring testing of the migration tools, 2) 
> support revert when things go wrong, and 3) minimize downtime.
> 
> -jhf-
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]