Open Stack

Scott Moser <smoser at ubuntu.com> wrote on 05/10/2013 03:50:24 PM:

> From: Scott Moser <smoser at ubuntu.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
> Date: 05/10/2013 03:55 PM
> Subject: Re: [openstack-dev] [nova][ironic] making file injection
> optional / removing it
>
> On Wed, 8 May 2013, Michael Still wrote:
>

>
> In that direction, for bare-metal, what I thought makes most sense is the
> following:
>  * images from openstack's perspective are just a bunch of blocks (in raw
>    format or qcow2 format) as opposed to a tarball of a root filesystem.
>  * installation of that image, pretty much looks like this:
>    convert-image-to-stdout input.img | dd if=- of=/dev/sda
>  * The image, then is in charge of handling the partition table or
>    otherwise making the OS boot.  Ie, your image is likely to be
>    partitioned and have grub installed in the master boot record or GPT
>    partitioned with EFI. The key thing here is that ironic pretty much
>    doesn't care.
>  * The "communication" mechanism from an image to ironic is via a
>    partition that is identified. For example we might choose to require
>    that there be a partition with a vfat filesystem.  In GPT, I think we
>    can actually identify it better by expecting for there to be a label
>    'config-v2'.  In DOS partition it would be 'Id' of '99' (or
something).
>
>  * After 'dd' of the image, ironic would then re-read the partition
>    tables, and search for this partition.
>    If it finds it, it can insert data like the data that goes into
>    config-drive-v2 (or some other format)
>  * The OS, when it boots reads this new "datasource" and operates the
same
>    way it does with ec2 metadata or openstack configdrive.
>
> The benefits of this path are:
>  a.) openstack has a 'contract' of sorts with images, rather than mucking
>      around inside them.
>  b.) The OS can handle bootloading itself (as opposed to having openstack
>      have to poke around inside looking for something name 'kernel' or
>      'initrmafs' or other such silly things. And also figure out what
>      kernel cmdline parameters it should hve.
>  c.) This can work for windows or bsd or whatever. The images are made
for
>      openstack.
>
> The first thing you'll say is that you dont like a partition laying aroud
> forever just for communication, but I think that is fine.  The OS can
deal
> with that.  Ie, heres one way:
>   /dev/sda1: EFI partition
>   /dev/sda2: small root filesystem
>   /dev/sda3: immediately following /dev/sda2
>
> The OS can come up, read the data from /dev/sda3 , copy it to its
> filesystem, then delete the partition and grow /dev/sda2 to take the rest
> of the disk.
>
> You may also not like the fact that the image basically has to be made to
> run with openstack/ironic.  I dont consider that a bad thing. Its no
> different then images being made to read the config-drive-v2.
>
> 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
-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)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130510/b69b8367/attachment.html>