AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070608153149.56ddb628@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.deforest@onstor.com>,<larry.scheer@onstor.com>,<tim.gardner@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 15:31:54 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian DeForest" <brian.deforest@onstor.com>
Cc: "Larry Scheer" <larry.scheer@onstor.com>, "Tim Gardner"
 <tim.gardner@onstor.com>
Subject: Re: Update on standalone install script
Message-ID: <20070608153154.3abb9af8@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

These bugs all need to be assigned to me if anyone wants them to be
addressed.  Is there some reason they aren't assigned to me?


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)
> TED00019482    cw_install.sh needs to have executable permission
> TED00019486    Should not prompt prior to reboot if user answered
> defect for interactive or unattended mode (from 2.1.0.4)
> TED00019490 	Users should not get the "You have successfully
> upgraded" message in subsequent logins post upgrade
> TED00019491 	Reword second paragraph of the install script
> introduction to make it less confusing
>  
> 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.
>  
> 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.
>  
> 
