Open Stack

On Wed, 8 May 2013, Michael Still wrote:

> I would not say that file injection is a requirement at the moment for
> a nova hypervisor driver. In fact, there's been discussion for a
> couple of releases about turning it off for everyone. I'd like to see
> it deprecated in Havana for removal in Incarceration [1] if at all
> possible. Some more discussion of if that's possible would be nice.
>
> However, I do think you need to support configdrive if you're not
> doing file injection. I say this because some deployments cannot use
> metadata server (for example, network policy may not allow instances
> to talk to infrastructure nodes). So, I think having that would be
> good.

I spoke with Robert at the summit, and have thought about "config-drive"
and bare-metal provisioning a bit since.

I really prefer openstack to generally offer a "platform" for images to
target.  Ie, the image is made so that it works well with openstack (it
reads data from config-drive or ec2-metadata) rather than openstack
making images work (file injection).

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.

Thoughts?