Open Stack

Scott Moser <smoser at ubuntu.com> wrote on 05/10/2013 05:06:01 PM:

> If you're going to deal with trying to know how to "install" something,
> then the best way to do it is to drive a supported installer.
>
> Ie, kickstart or preseed or some other mechanism, where the OS is
actually
> the one figuring out what drivers are needed and the like.
>

Well, adding the scripted install concept is something some of us are
considering offering.  ESXi and Windows installers are really just image
based anyway, so supporting a .wim file with a bunch of customized stuff is
nearly exactly the same as offering a .wim file with the base OS.

In terms of the trappings of driver injection, while I don't think
Openstack can maintain the actual drivers (technical and legal problems),
it wouldn't be a large stretch for it to provide a standardized framework
for hardware vendors to publish driver updates to.  Openstack could then
readily know how to combine the content from the software vendor with the
drivers from the hardware vendor.  The infrastructure maintainers and
hardware vendors they select have a better shot at knowing correct content
than image publishers.

For example, xCAT's driver architecture basically just takes whatever is in
$installresources/drivers/$osver/$arch/ and recognizes how to inject them
to windows, redhat, suse, and esxi.  Was thinking something like that.  The
Linux ones though work in conjunction with package-oriented installers
only, so if an image strategy is specifically desired for Linux on
baremetal in case of missing storage driver, then a bit of a new standard
would be needed, but on the same order of effort as recognizing a
standardized special partition.

The imaging support I only see as critical in the multi-tenant baremetal
case.  If the use case only covers hypervisors, then scripted install is
certainly sufficient.

Anyway, just food for thought.  The partition scheme is pretty good since
it's baked on such ubiquitous stuff, but the storage controller uncertainty
is just something that had repeatedly bit my team forcing us to add the
driver injection historically, and I don't see much hope for change in the
future.  firmware injection to memory requires a bit more os specific
choices as it stands, but not much to cover the BSDs, Linux, Windows, and
ESXi and you never have to worry about whether the target has driver
support for your ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130510/d4335222/attachment.html>