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:<Chuck.Nichols@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	660360F4F2570145BD872F298951B17AE332CE3A@cosmail03.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 16 Sep 2009 11:17:05 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Nichols, Chuck" <Chuck.Nichols@lsi.com>
Bcc: Brian Stark <brian.stark@lsi.com>
Subject: Re: Linux variants for Orion
Message-ID: <20090916111705.4f8ee7eb@ripper.onstor.net>
In-Reply-To: <660360F4F2570145BD872F298951B17AE332CE3A@cosmail03.lsi.com>
References: <660360F4F2570145BD872F298951B17AE332CE3A@cosmail03.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,

I'm working on a response to this, but first I had some questions which
I didn't feel I should bother the original list with.  I put them
inline.

 On Fri, 11 Sep 2009 16:10:13 -0600 "Nichols, Chuck"
<Chuck.Nichols@lsi.com> wrote:

> One of the items open for the Orion program is the selection of the
> specific Linux variant we'd like to use.  Fair warning... I'm NOT a
> Linux guru, so some of what comes next may not make any sense.  (And,
> btw, please jump in with any suggestions you might have.)  I don't
> think this effort needs to be exhaustive or too time consuming.  My
> gut says that, in the grand scheme of things, it "may not matter"
> what Linux variant we pick; we just need to pick one.  However, I
> would like to make an effort to at least identify if there are any
> critical showstoppers with a particular Linux variant that we'd much
> rather discover now rather than later.
> 
> As of right now, there are three "machines" in the architecture that
> will utilize some form of Linux OS: --Domain 0 (Dom0):  This we'll
> likely get from Citrix.  Right now it's a CENTOS variant with regards
> to tools, etc.  However the kernel is based upon OpenSUSE, version
> 2.6.27, if memory serves.

Why would we get this from Citrix?  Are we not putting together our own
setup with Xen and whatnot?  Is the thought that we might get some
benefit from paying Citrix for Xen?

> --NAS VM:  Porting work is underway to a Debian variant, largely due
> to that variant's support for a MIPS architecture.

And also largely due to the fact that it's already a Debian variant
~:^)  But I think it's largely irrelevant that we leverage Debian for
some things.  We make our own kernel which is probably more significant.

> --Service VM:  This is a general purpose VM for purposes of providing
> facilities that may be required across multiple VMs.  For example,
> SMI-S aggregation in the form of an embedded CIMOM, log collection
> and collation, etc.
> 
> Because Dom0 will come from Citrix, we need to nail down the specific
> Linux variant(s) we believe we should use for the NAS VM and the
> Service VM.  I'd like to suggest that the two VMs should use the same
> Linux variant.  While that may not be a "hard" requirement, I think
> it has some value from a development, build, and debug perspective,
> e.g. not having to track down different bugs in different Linux
> distributions.  Also, from an architectural perspective, having the
> two VMs sharing a common Linux distribution allows us some
> flexibility if we discover that portions of the architecture need to
> reside elsewhere (i.e. Service VM vs. NAS VM).

I've got some thoughts on how I think we should do all this.  Should I
put together a design document or similar for you to take a gander at,
and possibly pass around to folks for their thoughts?

> What I'd like to start by doing is making sure we've taken a good
> stab at collecting the list of what I'll call "Linux services" that
> are required for Orion.  These may be stand-alone User Space
> applications or Linux kernel modules.  For example, the Amelia work
> done so far has identified the following as required to be supported
> in the Service VM for management purposes:
> *       SFCB (embedded SMI-S CIMOM)
> *       some type of http server
> *       Libcurl
> *       openSLP
> *       openWSMan
> *       openSSL (fyi, Arindam has verified that a fairly serious
> security bug exists in Debian with regard to SSL)

As someone else pointed out, this is not the case.  If he's thinking
about what I think he's thinking about, it was with sshd, not ssl.  And
that was corrected ages ago.  Since bugs in Debian are fairly rare
compared to RHEL/Centos/Suse/Windows/etc, when they do happen they tend
to get a lot of "press."

> What else might be required, both for management and NAS?  Please
> reply to me and I'll start constructing that list

It's good to have a list.  Also keep in mind that if we do this right,
adding services or libraries relatively late should not pose a
problem.  I can't imagine that everything we wanted, plus some stuff we
haven't thought of yet, would amount to more than 100MiB.  If we got
really nutty, wanted to include X libraries and tomcat and so forth, it
might make it as high as 200MiB.  Both are probably pretty easily
accomodated, unless I miss my guess.

> Once we have a good idea of most of what is required, we can do a
> quick survey (I hesitate to use the work "analysis") of some likely
> Linux variants to determine if there is a best fit.  What are some of
> the likely Linux variants?  I think the requirements there are fairly
> straight-forward:
> *       We need to be able to strip it down to a fairly small
> footprint
> *       It needs to be bootable from flash
> *       It needs to be free (e.g. that rules out RHEL and SLES, but
> not CENTOS or OpenSUSE, if I understand correctly how those
> distributions work)
> *       What else?
> 
> I'm open to suggestions as to what variants we should consider.  Off
> the top of my head, CENTOS and OpenSUSE are probably on the list, as
> well as Debian or Ubuntu.  Perhaps there's a JEOS (Just Enough OS)
> variant we should consider.
> 
> Please give this some thought and/or respond with your perspective on
> additional requirements, required Apps/modules, and/or Linux
> variants.  This needs to be wrapped up by the end of the month,
> preferably sooner.  I will schedule a meeting early next week to
> discuss this.  Given that we'll have attendees in at least 3 or 4
> timezones, including Bangalore, I'll try to find a time that is
> appropriate; which usually means relatively early morning, California
> time.  (Andy and Bruce, how early in the morning would you be able to
> call in for a meeting?)

9am PDT.  Please.  Thanks.

> Thanks,
> Chuck
> 
