AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070608163126.79c0871c@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.deforest@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	BB375AF679D4A34E9CA8DFA650E2B04E040F1043@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 8 Jun 2007 16:32:27 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian DeForest" <brian.deforest@onstor.com>
Subject: Re: Update on standalone install script
Message-ID: <20070608163227.3595f8fe@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E040F1043@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E040F1043@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 Fri, 8 Jun 2007 15:26:39 -0700 "Brian DeForest"
<brian.deforest@onstor.com> wrote:

> FYI
> 
> _____________________________________________
> From: Sandrine Boulanger 
> Sent: Friday, June 08, 2007 1:49 PM
> To: dl-Delorean Core Team
> Subject: Update on standalone install script
> 
> We started all the tests of the install script this morning on all 4
> setups:
> - single node on 1.2.8.11 (Sandrine)
> - cluster on 1.3.3.17 (Brian)
> - single node on 2.1.0.4 (May)
> - cluster on 2.2.2.7 (John)
> Filers are configured with 250 cifs shares.
>  
> Here are the defects filed so far, the most critical one is 19489
> where it rebooted by itself to the same flash (maybe bsd crash but we
> could not find a proof) before the install was complete.
> Some are cosmetic defects, but since it is facing customers I think
> it's important that we address them.
>  
> TED00019489    cw_install.sh failed to upgrade filer g10r9 (first node
> in 2 node cluster)

silent reboot.  i thought we were past all that.  damn.

> TED00019482    cw_install.sh needs to have executable permission

possibly fixed by change in the work flow, as I believe it's ftp that
is stripping the execute permissions.

> TED00019486    Should not prompt prior to reboot if user answered
> defect for interactive or unattended mode (from 2.1.0.4)

WAD.  It doesn't prompt for reboot.  There is some noise from nfxsh
that I can't seem to quash, but otherwise works as expected.

> TED00019490 	Users should not get the "You have successfully
> upgraded" message in subsequent logins post upgrade

Not sure how to fix this.  Currently it removes the message the next
time the system is rebooted.  But that might be a long time I guess.

> TED00019491 	Reword second paragraph of the install script
> introduction to make it less confusing

Oh pish-posh, please.

> Erik B posted the install and tar files on the support site in a
> hidden directory and we verified the customer workflow of browsing
> the onstor ftp site to get the script and path to the release, using
> either the FQDN or the IP address of the ftp site.
>  
> For both single node upgrades, May and I found out that vsd was not
> restarted after the db was converted to 3.0 (this is a required step
> that should happen to have the upgrade really complete), and Chris
> said this is similar to the issue she is investigating with the # of
> shares, so we updated #19239 (P1).
>  
> Brian's mixed cluster (cheetah/bobcat) upgrade from 1.3.3.17 to 3.0
> worked fine; he saw vsd restart after the db was upgraded.

You mean one actually worked?  Scrape me off the pavement.

> For John's cluster (2.2.2.7), since he ran into 19489 the install did
> not complete, the cluster is in half upgraded mode. The script can
> probably be restarted on g10r9 to complete the upgrade, but we're
> waiting to now if DEV needs to collect more info on the filer right
> now.
> 
> We still need to test other workflows and specifics for the script,
> but I wanted to send an update of what we've experienced so far.
> 
> Note: We've noticed that the script does only one reboot, the final
> one that reboots to the secondary flash where 3.0 is installed. It
> looks like the recommended first reboot to clear the memory is not
> done by the script. We need to know if the user is responsible for
> running this step prior to running the script. From the spec review,
> this step was supposed to be part of the script.

I believe the spec says it will do an initial reboot if one is found to
be necessary.  It currently has not been found to be necessary.  If
that's not what the spec says, I'll fix the spec.

