X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C85E13.F6EBB1FE@onstor-exch02.onstor.net>; Wed, 23 Jan 2008 16:02:02 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: "system upgrade" vs. script for Cougar
Date: Wed, 23 Jan 2008 16:02:01 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E07D4F262@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: "system upgrade" vs. script for Cougar
Thread-Index: AchdTsxqZpdCQGBsQvCE63OQuB1r7gAv8hGQ
From: "Rich LaReau" <rich.lareau@onstor.com>
To: "Vikas Saini" <vikas.saini@onstor.com>,
	"Sudheesh Nair" <sudheesh.nair@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>,
	"Dennis Arellano" <dennis.arellano@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>
Cc: "Andrew LeFebvre" <andrew.lefebvre@onstor.com>


Hi team,

Yesterday after the core team meeting I reviewed the issues that Support
had with the "system upgrade" procedure.  The concerns and requirements
appear to come down to a few issues.  I wanted to get them out for
review, and then ask you what our next steps need to be. =20

The issues which are of CS concern are:

1)   Failed upgrades.  Before we used the scripts, it was common that we
would get upgrades which outright failed, or worse, appeared to work but
contained some corruption.  If we are to rely on "system upgrade" then
these issues need to be resolved.  By comparison, the scripts completely
blank the secondary flash and then copy everything in fresh.  This
avoids problems with copying cruft (old core files in odd places, repair
attempts, lost+found files, etc.) =20

2)  Time of upgrade.  This problem was primarily the result of needing
to download the entire tarball twice from the ftp server.  The scripts
are able to work with only one download.

3) Ease of use.  We do a lot of upgrades, so the process needs to be
simple-- both in the upgrade itself and the recovery process in case
something fails.


Some people had suggestions about how we might implement a good system
upgrade process:

A)  The system upgrade command should look in the downloaded tarball for
a script to execute.  If it exists, the script is run; if not, it uses
the old method.  That means if we do other flash card layouts, or even
more drastic changes, the script can manage all of that, and it will be
tied to the release bundle rather than having to be inserted earlier in
the development cycle.

B)  Standardize to the WebUI and replace the need for an FTP server all
together.  We could specify that the tar ball and md5 file are in the
same directory pick them both up and check them before install
commences, therefore ruling out a corrupt tar ball as a problem for the
installation. If we also had a new upgrade script we could have the
process look for this before commencing the installation as well,
replace the current install script and then start the process again. So
the process would be, go to the WebUI, open the system upgrade page,
point it the directory containing the scripts and click on the version
to install, then sit back get a coffee/tea and watch the status bar go
straight up to 90% before waiting another 30 minutes for the process to
complete (sorry this isn't MS is it!)
