Open Stack

On Fri, 10 May 2013, Jarrod B Johnson wrote:

> >
> > Cloud-init can support all of this with fairly straight forward changes.
> >
>
> Some additional concerns:
> -block format might not be as efficient as file oriented formats

> -The partition grow operation is frequently slower than FS creation

ext4 (resize2fs) is currently very good on growing.

You're right in that its not necessarily ideal, but it has many benefits.
Nothing says that the image *has* to grow its filesystem. you can surely
have a large full image (sparseness and compresssion delivered through
qcow2).

> -driver injection is a more critical thing in this flow given the wider
> variability of baremetal (though it is of significant value add to vm
> guests as well)

this is just about impossible to reliably do. In my mind its not something
openstack should even remotely attempt to do.  The entity that knows about
hardware and which drivers to use is the OS provider.

If you can't build "one image" that boots on all your available hardware,
then you can just build multiple and manage to deploy them to the right
hardware.

That said, i'm not entirely opposed to letting the user provide the
installer with "pre-user-data" that would run after blat before reboot.


> As a mechanism of last resort, it seems to make sense, but it may make
> sense to support os platform specific mechanisms for the most prominent
> OSes as well.  It's not that difficult to support that.  Windows PE boot
> for .wim related deployments, ESXi boot for ESXi deployments, etc.

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.