AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080123153109.5cbb5d1d@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<rich.lareau@onstor.com>,<vikas.saini@onstor.com>,<sudheesh.nair@onstor.com>,<tim.gardner@onstor.com>,<dennis.arellano@onstor.com>,<andrew.lefebvre@onstor.com>,<larry.scheer@onstor.com>,<caeli.collins@onstor.com>,<paul.hammer@onstor.com>,<brian.stark@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E07D4F262@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 23 Jan 2008 15:31:54 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Rich LaReau" <rich.lareau@onstor.com>
Cc: "Vikas Saini" <vikas.saini@onstor.com>, "Sudheesh Nair"
 <sudheesh.nair@onstor.com>, "Tim Gardner" <tim.gardner@onstor.com>, "Dennis
 Arellano" <dennis.arellano@onstor.com>, "Andrew LeFebvre"
 <andrew.lefebvre@onstor.com>, Larry Scheer <larry.scheer@onstor.com>, Caeli
 Collins <caeli.collins@onstor.com>, Paul Hammer <paul.hammer@onstor.com>,
 Brian Stark <brian.stark@onstor.com>
Subject: Re: "system upgrade" vs. script for Cougar
Message-ID: <20080123153154.4739dd2f@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E07D4F262@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E07D4F262@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 23 Jan 2008 15:02:01 -0800 "Rich LaReau"
<rich.lareau@onstor.com> wrote:

> 
> 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.  
> 
> 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.)  

I think this is largely an old perception.  I personally know of all
these problems you mentioned being fixed at least by the 3.0 release
if not sooner. At this point in time, and consider that this is the
person who originally wrote the install script saying this, if I it was
my customer, and I was upgrading from a 3.x to a 3.x, I would use system
upgrade.  Or flash_install with auto-upgrade.

Note that there is a workflow that uses system upgrade that does what
you mention in terms of wiping the CF card and installing fresh. Doing
a _system copy init_ followed by a _system upgrade_.  Code was
specifically added to make this possible.

> 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.

As I understand it, many SEs make a flash with flash_install.sh before
they head to the customer site, and set it to auto-upgrade when it is
booted. That means that you can just insert the flash card in the
secondary slot, and do a reboot.  When it boots, it copies the
configuration info from the other flash card.  For down time, this is
definitely the fastest way to go, but obviously there are a lot of
caveats to that as well, not the least of which is logistical, which
prevents us (I'm told) from making this our default upgrade procedure.

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

Excellent.  Ideas always most welcome.  Keep 'em coming.  Often.

> 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.

This is the way it actually works now.  Believe me when I say that this
has been long thought of and desired.  Because of the current design of
executing a script from the upgrade tarball itself, many changes can be
made in one release, but not all.  For instance, being able to use HTTP
as well as FTP, well, that's going into the next release, but it won't
help when upgrading to that release.  But eventually it will help.

> 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!)

Sounds good to me!  Let us know when you've got something to test!  And
yes, that is on my list of faves but earliest would be post Cougar
release, and no, it's not on any schedule.  Keep in mind that
implementing this is no small project, and I'm not even including the
WebUI development part.  Ease of use is not always easy to do ~:^)

Cheers,

a
