X-Sylpheed-Account-Id:2
S:andy.sharp@lsi.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/LSI/INBOX	0	F9DCB1C30AC37B4EB352D0DE0AE18E5F97D921AE@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 9 Oct 2009 10:42:15 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Rolandelli, Craig" <Craig.Rolandelli@lsi.com>
Cc: "Edge, Bruce" <Bruce.Edge@lsi.com>, "Nichols, Chuck"
 <Chuck.Nichols@lsi.com>, "Henry, Jason" <Jason.Henry@lsi.com>
Subject: Re: Xen alignment options
Message-ID: <20091009104215.64cb7e3c@ripper.onstor.net>
References: <4ACF4E65.7010003@lsi.com>
	<20091009092936.38df3035@ripper.onstor.net>
	<F9DCB1C30AC37B4EB352D0DE0AE18E5F97D921AE@cosmail02.lsi.com>
Organization: LSI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.

Good god.  That's an astoundingly ignorant and prejudiced thing to
say.  And frankly, I wasn't aware of your extended expertise with open
source and the community development model.  This is classic FUD
spreading.  You're painting developers in the community as hairy hippies
with no responsibilities or acumen. However, that's exactly who
developes Xen, precisely the thing you are espousing we base this
product on.  It's community developed.  BTW, I contribute a lot of code
to open source projects, and yes, I am a hairy hippy.  But I do have
skills. Mad skills.  And I've deliverd a hell of a lot of products to
customers.

> 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.

This goes much lower down that some under-informed managers looking at
feature lists on a piece of paper.  Picking the right thing and moving
forward with it is exactly what we're trying to do.  FUD isn't helping
make that choice.

> 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.

See my previous comment.

> 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.

Let's put a stop on that check.  Or perhaps just endorse it over to
Bruce's group.

Why is it logical to pay Citrix many hundreds of thousands of dollars,
which to my knowledge hasn't been paid yet, to do something that we
can do ourselves for almost certainly much less money?  Citrix doesn't
develop the kernel portion of Xen. That's all community developed and
supported.

> 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).

Again, this is what I would call a classic mischaracterization of the
situation.  Classic because it's the non-open source way of looking at
the world, misapplied to the open source approach we're taking, and
that's all too common.  There's a lot of things we "aren't" -- but
don't use that kind of stampede mentality in place of a properly arrived
at technical decision.

> Craig

Andy

> 
> -----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
