AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Nelson.Nahum@lsi.com>,<Chuck.Nichols@lsi.com>,<Bruce.Edge@lsi.com>,<Jason.Henry@lsi.com>,<Brian.Stark@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	3D228269E7866B4B85BE8E4FC5A4447A10AD68@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 12 Oct 2009 11:27:20 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Nahum, Nelson" <Nelson.Nahum@lsi.com>
Cc: "Nichols, Chuck" <Chuck.Nichols@lsi.com>, "Edge, Bruce"
 <Bruce.Edge@lsi.com>, "Henry, Jason" <Jason.Henry@lsi.com>, "Stark, Brian"
 <Brian.Stark@lsi.com>
Subject: Re: Xen alignment options
Message-ID: <20091012112720.57f38ba5@ripper.onstor.net>
In-Reply-To: <3D228269E7866B4B85BE8E4FC5A4447A10AD68@cosmail02.lsi.com>
References: <4ACF4E65.7010003@lsi.com>
	<20091009092936.38df3035@ripper.onstor.net>
	<F9DCB1C30AC37B4EB352D0DE0AE18E5F97D921AE@cosmail02.lsi.com>
	<20091009104956.598697fe@ripper.onstor.net>
	<3D228269E7866B4B85BE8E4FC5A4447A10AD68@cosmail02.lsi.com>
Organization: LSI
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, 9 Oct 2009 13:36:56 -0600 "Nahum, Nelson"
<Nelson.Nahum@lsi.com> wrote:

> Hi Andy,
> 
> I didn't follow up all the email thread but it seems that you are
> questioning why we do Xen with Citrix and not from the Open Source.
> If this is the case, I can understand some of your arguments, but
> this is already a done deal and even if this sounds stupid, I suggest
> to adapt to the idea and move on.
> 
> As I said in my presentation the first day, we really need to fight
> for our ideas, but we need to be the first to embrace the decisions,
> otherwise we will never get things done. Usually there are any pro's
> and cons' with any alternative we choose.

I understand all that quite well.  This is not about any of those
things.  And for the record, I said it's the amount of money that's
stupid, not the idea.  What made me angry was the way he spammed people
like myself, and hundreds of others that I know, including several that
are my friends.  All of whom know more about developing and shipping a
product than ... well, you get the idea.

Changing the subject, I'm unaware of it being a done deal.  I
thought we were still working on the statement of work, which would
usually mean nothing is signed yet.  Of course, I could be misinformed.

> Nelson
> 
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Friday, October 09, 2009 10:50
> To: Nichols, Chuck
> Cc: Edge, Bruce; Henry, Jason; Stark, Brian; Nahum, Nelson
> Subject: Re: Xen alignment options
> 
> Hi Chuck,
> 
> Holy cow, what a complete tool.  What's this guy's deal?  Chuck, you
> mentioned that there's some learning curve with regard to the open
> source model at LSI, but this email hits them all: community
> developers (of which I'm one) are a bunch of shiftless hippies who
> wouldn't know a product if it ran them over; it's about features; we
> aren't in the XXXX business, therefore YYYY unrelated conclusion;
> paying a company a STUPID amount of money (.5 mil? more?) guarantees
> quality, support and service exactly as we imagine we want.
> 
> I *seriously* don't have time for this n0b.
> 
> On Fri, 9 Oct 2009 11:02:03 -0600 "Rolandelli, Craig"
> <Craig.Rolandelli@lsi.com> wrote:
> 
> > The problem with folks who "own" code in the open source is that
> > they typically don't have to deliver products to customers.  We are
> > in the business of delivering storage products that must work 100%
> > of the time.  We are not in the business of shipping the latest and
> > greatest virtualization software.  We need to develop and test on
> > stable, tested, hardened platforms.
> > 
> > We need to pick a release and move forward with it.  If Xen 3.4.1
> > has the features we need for this product today, then we should use
> > it. If it doesn't, then we need to know that now and deal with it.
> > I haven't heard that there are any feature set issues with 3.4.1 for
> > what we need to deliver for Orion.
> > 
> > If new features come up in Xen 3.5 that we could use, then I would
> > consider that feature creep and should be kept out of this release
> > of the product.
> > 
> > If there is a stability issue with 3.4.1 and we need a fix in 3.5,
> > then that fix needs to be back ported by Citrix to 3.4.1.  Citrix is
> > being paid a lot of money by us to support us and to deliver a
> > stable, tested hardened release of Xen.
> > 
> > Again, we aren't in the business of shipping the latest and greats
> > virtualization software.  We are in the business of shipping storage
> > platforms that have 100% availability (or at least 5 9's
> > availability).
> > 
> > Craig
> > 
> > 
> > -----Original Message-----
> > From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> > Sent: Friday, October 09, 2009 9:30 AM
> > To: Edge, Bruce
> > Cc: Rolandelli, Craig; Nichols, Chuck
> > Subject: Re: Xen alignment options
> > 
> > On Fri, 9 Oct 2009 08:53:25 -0600 "Edge, Bruce" <Bruce.Edge@lsi.com>
> > wrote:
> > 
> > > Craig, Chuck, Andy,
> > > 
> > > I'm not convinced that a Citrix XenServer is the best option for
> > > LSI even if support is the primary reason. If we were using Xen
> > > for server consolidation in an IT environment that would be a
> > > different story, but we're not.
> > > 
> > > We have recently been working through a problem with the MSI in
> > > Xen relating to IRQ affinity. One day after posting the problems
> > > details on the xen-devel list, we were directed to the author of
> > > that code within Xen, who subsequently told us what debug options
> > > to add, and a request for more information. This Xen developer
> > > also states that we're better off with the leading edge, Xen 3.5
> > > (unstable), for new development work especially for new hardware
> > > support.
> > > 
> > > The fact is that we're developing kernel code on leading edge
> > > hardware that's pushing the development envelope of Xen itself. I
> > > can't see how committing to using an earlier static version of Xen
> > > is the best option for those requirements.
> > > 
> > > -Bruce
> > 
> > I concur.  This sort of thing will be continuing occurance.  Put
> > another way, I don't believe there's a "no-brainer" way of doing
> > this.
> > 
> > a
