AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080606161115.59b8ca79@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<sandrine.boulanger@onstor.com>,<raj.kumar@onstor.com>,<dl-engineering@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	BB375AF679D4A34E9CA8DFA650E2B04E09CB81D7@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 6 Jun 2008 16:12:11 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Sandrine Boulanger" <sandrine.boulanger@onstor.com>
Cc: "Raj Kumar" <raj.kumar@onstor.com>, "dl-Engineering"
 <dl-engineering@onstor.com>
Subject: Re: Upgrades and Bobcat/Cheetah to Cougar replacement processes
Message-ID: <20080606161211.4b848426@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E09CB81D7@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0422923F@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E09CB81D7@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

Comments inline.

On Thu, 5 Jun 2008 17:35:30 -0700 "Sandrine Boulanger"
<sandrine.boulanger@onstor.com> wrote:

> I did not get much feedback besides Raj's. I'm just going to decide on
> something and send it to the Cougar core team tomorrow :-)
> 
> Speak now if you have some comments.
> 
> ________________________________
> 
> From: Raj Kumar 
> Sent: Thursday, June 05, 2008 6:58 AM
> To: Sandrine Boulanger; dl-Engineering
> Subject: RE: Upgrades and Bobcat/Cheetah to Cougar replacement
> processes
> 
>  
> 
> Since this is a replacement process do we need to provide the expected
> downtime for this process? May be some rough numbers? 
> 
>  
> 
> If fs version 29 is critical moving forward cant we make it as an
> automatic conversion when they upgrade to 3.3/4.0? This shouldn't add
> too much of downtime for most of the volumes. 
> 
> > Yes, I think we can make that a required step.
> 
>  
> 
> Replacing BC with cougar: Should we suggest the following process? 
> 
> (1) 3.3 is a pre-requisite
> 
> (2) Once upgraded to 3.3 fs conversion and EEK run are mandatory
> 
> (3) then proceed with replacement procedure
> 
> > OK
> 
>  
> 
> For the sites with DMIP implemented, do we need to provide some
> special procedure. Since we support DMIP between CG and BC, may be
> the customer would like to replace the source cluster to CG and not
> replace the target cluster or vice versa or replace target cluster at
> later time. If we do force or recommend mandatory EEK before the
> replacement, do we also need to suggest to perform a mirror sync
> before they proceed with the replacement?
> 
> > we need to agree to which Bobcat release we can run DMIP from
> > Cougar.
> Maybe we support it only if they upgrade their Bobcats to 3.3 

Couple of questions:

Will Cougars even do filesystems with version less than 29?  They
probably shouldn't, should they?  Of course, if someone doesn't follow
the correct procedure and tries to transition to a cougar with a sub-29
filesystem, they could be up the creek.  Cougar could simply require
that you convert the filesystem before you can online it.

Do source and target have to be the same filesystem version?

If replacing just the source, then I assume a full 3.3 procedure on
both source and target nodes must be completed before the source can be
transitioned to cougar.

> I think we have to test, document and support the process of going
> back to BC in case cougar installation failiure.
> 
>  
> 
> On a separate note the new EEK will throw several volume exception in
> case of the older volume not being EEK'd before upgrade. How do we
> want handle this? Do we need this to be configurable? Instead of
> exceptions may be an error?
> 
> > Jobi?
> 
>  
> 
> ________________________________
> 
> From: Sandrine Boulanger
> Sent: Wed 6/4/2008 8:55 PM
> To: dl-Engineering
> Subject: Upgrades and Bobcat/Cheetah to Cougar replacement processes
> 
> I'm trying to summarize here what we discussed in last Cougar
> engineering meeting. If everyone agrees, I'll send this to the core
> team.
> 
> Upgrades to 3.3:
> 
> Cheetah: Not supported
> 
> Bobcat:
> 
>         From releases prior to 3.0: use the 3.3 install script, and
> then recommended to EEK all volumes
> 
>         From releases 3.x: system copy all (we don't know what's on
> the other flash), system upgrade -s, system reboot -s; EEK not
> necessary (?)

Might as well make it a _system copy init_ in that case.  Takes less
time.  Unless they have "upgrade un-safe customizations" they don't
want deleted.

> Upgrades post 4.0:

or 3.3

> No more install script.
> 
> Use: 
> 
> 1.      system copy init - again, we don't know what's on the other
> flash 
> 2.      system upgrade -s 
> 3.      system reboot -s 
> 
> Bobcat/Cheetah to Cougar replacement (better word than migration since
> it seems to confuse people who think data migration)
> 
> Cheetah (only 8 customers): 
> 
> Pre-requisite release to run before doing the replacement: since 3.3
> is not supported for Cheetah, to which release should we upgrade
> first? 3.2.0.5 will not be GA (but could we use it for this
> situation?). Main question is: where does the requirement to run 3.2
> before replacing the units comes from? I know about the flash layout
> change, but that was introduced in 3.0. So if they are running 3.0 or
> later, can they just go ahead with the replacement?
> 
> I would prefer we pick one (3.2.0.5 or 3.1.1.), less combinations to
> test/support

Fine by me.

> Bobcat:
> 
> Pre-requisite release to run before doing the replacement: same
> question here for Bobcat. We could have 3.3 be the pre-requisite
> release in that case.
> 
> FS conversion: do we want to add a step that they convert all their
> file systems to version 29 before proceeding with the replacement?

Like Raj said, they are going to have down time so might as well.

> Support for going back to Bobcats if something goes wrong during the
> replacement when Cougars are coming up: should we
> test/document/support this? Simple to achieve with the right
> manipulation of the flashes. Would just need to re-cable and re-zone
> the luns back.

Those what have gone 'Coug' never go back.

> Support for re-provisioning the Bobcats after Cougars are deployed:
> should we test/document/support this? With a few simple steps (unplug
> network cables and system config reset through ssc console port), this
> can be done too.

Since we don't try to snake the MAC address anymore when
migrating^Wtransitioning from a Bobcat to a Cougar, if _system config
reset_ works, this will work. If they want to get rid of the Bobcat,
they can send it to me, I've got some uneven spots in my driveway.
Sha, of course I'll take the memory out first.  ripper still has 4
empty slots.

> Please provide your feedback by Friday.
> 
> Thanks,
> 
> Sandrine
> 
