AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080204111117.510614d9@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<joshua.goldenhar@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	BB375AF679D4A34E9CA8DFA650E2B04E0812B343@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 4 Feb 2008 11:11:32 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Joshua Goldenhar" <joshua.goldenhar@onstor.com>
Subject: Re: Beta Readiness Criteria Document
Message-ID: <20080204111132.1361ae6b@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0812B343@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0812AF9A@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E080CB04C@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0812B255@onstor-exch02.onstor.net>
	<20080204103140.74c30ed1@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0812B2E6@onstor-exch02.onstor.net>
	<20080204105543.27683f97@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0812B343@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 Mon, 4 Feb 2008 11:07:54 -0800 "Joshua Goldenhar"
<joshua.goldenhar@onstor.com> wrote:

> 
> > -----Original Message-----
> > From: Andy Sharp
> > Sent: Monday, February 04, 2008 10:56 AM
> > To: Joshua Goldenhar
> > Subject: Re: Beta Readiness Criteria Document
> > 
> > On Mon, 4 Feb 2008 10:39:33 -0800 "Joshua Goldenhar"
> > <joshua.goldenhar@onstor.com> wrote:
> > 
> > > Oh andy - don't start the religious crap ;-)
> > 
> > Please don't embarrass yourself by trying to put this on me, and
> please
> > don't try to discount my legitimate comments by terming them
> 'religious
> > crap'. The fact is, you should know better than to use HTML email.
> [Josh Replies] 
> Andy -
> I didn't "put it on you" - I acknowledged your complaint and admitted
> that "I've gotten lazy".

OK.  I didn't get that, so perhaps I took it wrong.  My apologies.

> > 
> > Set outlick to compose in plain text, use the standard internet
> quoting
> > convention, and all works just fine.
> [Josh Replies] 
> You're still discounting the fact that most people outside engineering
> in this company as well as most of the people I communicate with
> outside of ONStor know nothing of "standard internet quoting
> convention".
> 
> > 
> > No one ever tells me that my emails show up as blank in Outlook, so
> > there is a good method that works for all.
> > 
> > > The responses show up in a different color in outlook - probably
> > > in Evolution too.
> > 
> > I don't use either one, and believe me, I wouldn't mention it if my
> > email client made these readable.  I can open them up in a browser
> > and they are different colors: blue and black.  Besides the fact
> > that it's really quite hard to tell the difference, I can't reply
> > with that method.  If I could, I wouldn't say a word.
> > 
> > > If I make outlook use the old/unix-accepted reply method of
> > > quoting "> " and put all responses in-line, most Windows users
> > > have no clue
> -
> > > I've gotten back emails that say "Your reply was blank..."
> > 
> > First you have to set "plain/text" as the default/main compose
> > method.
> [Josh Replies] 
> I've already made some changes and for now I've set my default
> composition method to plain text.
> 
> We'll see how it goes.

Let me know if it doesn't go all right.  Then at least I know I have
more work to do to "fit in."
 
> josh
> > 
> > > So there is not really a good method that works for all. I hate
> > > top-posted replies but that's what most Windows users expect and
> most
> > > of my communications are with windows users, so I've gotten lazy.
> > >
> > > I'll check the Outlook options again and see if there's a better
> > > response option...
> > >
> > > In the mean time, I gave an answer to every one of Paul's
> > > questions
> so
> > > the sentence after the newline is my response.
> > >
> > > -Josh
> > >
> > > Josh Goldenhar
> > > Phone: 408 963 2408, Cell: 408 547 7693
> > >
> > > -----Original Message-----
> > > From: Andy Sharp
> > > Sent: Monday, February 04, 2008 10:32 AM
> > > To: Joshua Goldenhar
> > > Subject: Re: Beta Readiness Criteria Document
> > >
> > > Hi Josh,
> > >
> > > Sooo, which are the comments and which are the responses?
> > >
> > > On Mon, 4 Feb 2008 10:02:21 -0800 "Joshua Goldenhar"
> > > <joshua.goldenhar@onstor.com> wrote:
> > >
> > > > Responses in-line below..
> > > >
> > > >
> > > >
> > > > -Josh
> > > >
> > > > Josh Goldenhar
> > > > Phone: 408 963 2408, Cell: 408 547 7693
> > > >
> > > > ________________________________
> > > >
> > > > From: Paul Hammer
> > > > Sent: Sunday, February 03, 2008 12:16 PM
> > > > To: Joshua Goldenhar; dl-Cougar
> > > > Subject: RE: Beta Readiness Criteria Document
> > > >
> > > >
> > > >
> > > > Thanks Josh, very helpful and a good start.
> > > >
> > > >
> > > >
> > > > Sandrine is correct, we do not currently have plans/requirements
> to
> > > > increase the number of vsvr's or volumes. Also believe that the
> >2tb
> > > > lun will only be available by FCS, won't make beta.
> > > >
> > > > Hmm - OK, did that drop out while I was away? Did it move to keg
> or
> > > > is it off the table all together. I didn't think the lun label
> stuff
> > > > would make Beta, that's why I put it in "desired" instead of
> > > > required. I removed the >32 vservers.
> > > >
> > > >
> > > >
> > > > Assume where the docs says 2 node cluster it means 2 mother
> > > > boards and 1 physical chassis. Believe that QA is already
> > > > testing with a
> 2
> > > > physical chassis and 4 mother board cfg, Vikas can you confirm?
> > > >
> > > > Yes - I believe we will only be sending out single chassis, dual
> > > > node systems.
> > > >
> > > >
> > > >
> > > > So for beta it looks like we only require 3 switches and 2
> > > > storage arrays supported (only surprise to me was the absence
> > > > of Nexsan). This is good. What is a V100 Pantera? Is this
> > > > Xyratex?
> > > >
> > > > Yes, the V100 is the Xyratex 5404 storage. No Nexsan in the beta
> > > > customers and we want to start de-emphasizing our support for
> Nexsan
> > > > since we will push the V100 as a denser alternative.
> > > >
> > > >
> > > >
> > > > Can you let us know what DMA we need qualified (if any) , and
> > > > with what tape device?
> > > >
> > > > None - I put NDMP and backup apps in the "desired" section. If
> > > > we get any, it's a bonus. NetBackup would probably top the
> > > > list. LT03 and 04 tape drives. Doc has been updated.
> > > >
> > > >
> > > >
> > > > Client support looks good, not sure we need NT (can't recall if
> > > > we even support today outside of an AD host), no Mac support?
> > > >
> > > > Mac support is thorny because of the leopard issue. Last I heard
> we
> > > > were considering this an apple problem, not ours to fix, that
> Apple
> > > > would be coming out with a patch. Has that changed?
> > > >
> > > >
> > > >
> > > > Thought we discussed DMIP at the team meeting last week and
> > > > agreed that we did not have to have this support, although
> > > > Cougar to
> Bobcat
> > > > and vice a versa is a feasible combination. I am okay with
> > > > adding
> it
> > > > if it will help with the beta should not be hard to test, don't
> > > > think there is any incompatibility between the two. Ditto for
> > > > vol import.
> > > >
> > > > I'm OK moving DMIP (cougar-Cougar) to "desired" as Sandrine was
> > > > right that it is unlikely to be tested. I would like to keep vol
> > > > import in required but is this important to test if the LUN
> > > > label work is NOT there?
> > > >
> > > >
> > > >
> > > > Given our customer base I would think that we may need to
> > > > require Copper SFP's support for beta.
> > > >
> > > > Yep.
> > > >
> > > >
> > > >
> > > > Josh, are we providing and Pantera's for beta (Cougar with
> > > > Storage pre configured), or are we only providing Cougar?
> > > >
> > > > I believe we are only supplying Cougar HW, no storage.
> > > >
> > > >
> > > >
> > > > Are we going to require a beta refresh during the beta (forces
> > > > testing of upgrade in the field, think that would be a good
> > > > test)?
> > > >
> > > > I think it's inevitable - I thought I had put system upgrade in
> must
> > > > have but I see it's missing, adding it to the doc.
> > > >
> > > >
> > > >
> > > > Post Beta Completion questions (not sure that they belong in the
> > > > readiness doc but thought I would ask):
> > > >
> > > > Do we have to retain user data created during the beta?
> > > >
> > > > Nope.
> > > >
> > > > Do we have to retain configuration data created during the beta?
> > > >
> > > > Nope
> > > >
> > > > Do we have to have a way to migrate a cougar from Beta code to
> > > > production code?
> > > >
> > > > Hmm - The last discussion I was involved in said we were going
> > > > to bring the Beta units back home, that the units that went out
> > > > for beta would not be converted to sales - at least not the
> > > > actual physical units themselves. I suppose much of the answer
> > > > to this question lies with "Will the beta units be complete HW
> > > > final versions, at final versions of PROM code?" and if system
> > > > upgrade works properly. Will have to investigate.
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > >
> > > > -Paul
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: Joshua Goldenhar
> > > > Sent: Sun 2/3/2008 9:59 AM
> > > > To: dl-Cougar
> > > > Subject: Beta Readiness Criteria Document
> > > >
> > > > First released draft is attached. It will be kept and maintained
> in:
> > > >
> > > > \\mightydog\Program Management\Cougar\Marketing
> > > >
> > > > -Josh
> > > >
> > > > Josh Goldenhar
> > > > Sr. Dir. Technical Strategy
> > > > ONStor, Inc. - http://www.onstor.com/
> > > > joshua.goldenhar@onstor.com
> > > > Phone: 408 963 2408, Cell: 408 547 7693
> > > >
> > > >
> > > >
