<html><body>
<p><tt><font size="2">Scott Moser <smoser@ubuntu.com> wrote on 05/10/2013 03:50:24 PM:<br>
<br>
> From: Scott Moser <smoser@ubuntu.com></font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org></font></tt><br>
<tt><font size="2">> Date: 05/10/2013 03:55 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [nova][ironic] making file injection <br>
> optional / removing it</font></tt><br>
<tt><font size="2">> <br>
> On Wed, 8 May 2013, Michael Still wrote:<br>
> <br>
<br>
> <br>
> In that direction, for bare-metal, what I thought makes most sense is the<br>
> following:<br>
> * images from openstack's perspective are just a bunch of blocks (in raw<br>
> format or qcow2 format) as opposed to a tarball of a root filesystem.<br>
> * installation of that image, pretty much looks like this:<br>
> convert-image-to-stdout input.img | dd if=- of=/dev/sda<br>
> * The image, then is in charge of handling the partition table or<br>
> otherwise making the OS boot. Ie, your image is likely to be<br>
> partitioned and have grub installed in the master boot record or GPT<br>
> partitioned with EFI. The key thing here is that ironic pretty much<br>
> doesn't care.<br>
> * The "communication" mechanism from an image to ironic is via a<br>
> partition that is identified. For example we might choose to require<br>
> that there be a partition with a vfat filesystem. In GPT, I think we<br>
> can actually identify it better by expecting for there to be a label<br>
> 'config-v2'. In DOS partition it would be 'Id' of '99' (or something).<br>
> <br>
> * After 'dd' of the image, ironic would then re-read the partition<br>
> tables, and search for this partition.<br>
> If it finds it, it can insert data like the data that goes into<br>
> config-drive-v2 (or some other format)<br>
> * The OS, when it boots reads this new "datasource" and operates the same<br>
> way it does with ec2 metadata or openstack configdrive.<br>
> <br>
> The benefits of this path are:<br>
> a.) openstack has a 'contract' of sorts with images, rather than mucking<br>
> around inside them.<br>
> b.) The OS can handle bootloading itself (as opposed to having openstack<br>
> have to poke around inside looking for something name 'kernel' or<br>
> 'initrmafs' or other such silly things. And also figure out what<br>
> kernel cmdline parameters it should hve.<br>
> c.) This can work for windows or bsd or whatever. The images are made for<br>
> openstack.<br>
> <br>
> The first thing you'll say is that you dont like a partition laying aroud<br>
> forever just for communication, but I think that is fine. The OS can deal<br>
> with that. Ie, heres one way:<br>
> /dev/sda1: EFI partition<br>
> /dev/sda2: small root filesystem<br>
> /dev/sda3: immediately following /dev/sda2<br>
> <br>
> The OS can come up, read the data from /dev/sda3 , copy it to its<br>
> filesystem, then delete the partition and grow /dev/sda2 to take the rest<br>
> of the disk.<br>
> <br>
> You may also not like the fact that the image basically has to be made to<br>
> run with openstack/ironic. I dont consider that a bad thing. Its no<br>
> different then images being made to read the config-drive-v2.<br>
> <br>
> Cloud-init can support all of this with fairly straight forward changes.<br>
> <br>
</font></tt><br>
<tt><font size="2">Some additional concerns:</font></tt><br>
<tt><font size="2">-block format might not be as efficient as file oriented formats </font></tt><br>
<tt><font size="2">-The partition grow operation is frequently slower than FS creation</font></tt><br>
<tt><font size="2">-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)</font></tt><br>
<br>
<tt><font size="2">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.</font></tt><br>
</body></html>