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:<Bruce.Edge@lsi.com>,<Chuck.Nichols@lsi.com>,<Jason.Henry@lsi.com>,<brian.stark@lsi.com>,<Nelson.Nahum@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	F9DCB1C30AC37B4EB352D0DE0AE18E5F97D921AE@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 9 Oct 2009 10:49:56 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Nichols, Chuck" <Chuck.Nichols@lsi.com>
Cc: "Edge, Bruce" <Bruce.Edge@lsi.com>, "Henry, Jason"
 <Jason.Henry@lsi.com>, Brian Stark <brian.stark@lsi.com>, Nelson Nahum
 <Nelson.Nahum@lsi.com>
Subject: Re: Xen alignment options
Message-ID: <20091009104956.598697fe@ripper.onstor.net>
In-Reply-To: <F9DCB1C30AC37B4EB352D0DE0AE18E5F97D921AE@cosmail02.lsi.com>
References: <4ACF4E65.7010003@lsi.com>
	<20091009092936.38df3035@ripper.onstor.net>
	<F9DCB1C30AC37B4EB352D0DE0AE18E5F97D921AE@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

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
