Monthly Archives: December 2014

OpenStack Ironic is a bare metal as a service deployment tool. Fedora Atomic is a µOS consisting of a very minimal installation of Linux, kernel.org, Kubernetes and Docker. Kubernetes is an endpoint manager and container scheduler, while Docker is a container manager. The basic premise of Fedora Atomic using Ironic is to present a lightweight launching mechanism for OpenStack.

The first step in launching Atomic is to make Ironic operational. I used devstack for my deployment. The Ironic developer documentation is actually quite good for a recently Integrated OpenStack project. I followed the instructions for devstack. I used pxe+ssh, rather then the agent+ssh. The pxe+ssh driver virtualizes bare-metal deployment for testing purposes, so only one machine is needed. The machine should have 16GB+ of RAM. I find 16GB a bit tight, however.

I found it necessary to hack devstack a bit to get Ironic to operate. The root cause of the issue is that libvirt can’t write the console log to the home directory as specified in the localrc. To solve the problem I just hacked devstack to write the log files to /tmp. I am sure there is a more elegant way to solve this problem.

It took me two days to sort out the project in this blog post, and during the process, I learned a whole lot about how Ironic operates by code inspection and debugging. I couldn’t find much documentation about the deployment process so I thought I’d share a nugget of information about the deployment process:

Nova contacts Ironic to allocate an Ironic node providing the image to boot

Ironic pulls the image from glance and stores it on the local hard disk

Ironic changes the PXEboot configuration to point to the user’s actual desired ramdisk and kernel

The deploy node reboots into SEABIOS again

The node boots the proper ramdisk and kernel, which load the disk image that was written via iSCSI

Fedora Atomic does not ship images that are suitable for use with the Ironic model. Specifically what is needed is a LiveOS image, a ramdisk, and a kernel. The LiveOS image that Fedora Cloud does ship is not the Atomic version. Clearly it is early days for Atomic and I expect these requirements will be met as time passes.

But I wanted to deploy Atomic now on Ironic, so I sorted out making a PXE-bootable Atomic Live OS image.

The Atomic cloud image has /dev/sda1 containing the contents of the /boot directory. The /dev/sda2 partition contains a LVM partition. There is a logical volume called atomicos/root which contains the root filesystem.

Building the Fedora Atomic images for Ironic is as simple as extracting the ramdisk and kernel from /dev/sda1 and extracting /dev/sda2 into an image for Ironic to dd to the iSCSI target. A bit complicating is that the fstab must have the /boot entry removed. Determining how to do this was a bit of a challenge, but I wrote a script to automate the Ironic image generation process.

The first step is to test that Ironic actually installs via devstack using the above localrc:

[sdake@bigiron devstack]$ ./stack.sh
bunch of output from devstack ommitted
Keystone is serving at http://192.168.1.124:5000/v2.0/
Examples on using novaclient command line is in exercise.sh
The default users are: admin and demo
The password: 123456
This is your host ip: 192.168.1.124

Next, take a look at the default image list which should look something like:

In this case, we want to boot the UEC image. Ironic expects properties attached to the image ramdisk_id and kernel_id which are the UUIDs of cirros-0.3.2-x86_64-uec-kernel and cirros-0.3.2-x86_64-uec-ramdisk.

Next we configure Ironic’s PXE boot config options and restart the ironic conductor in devstack. To restart Ironic conductor use screen -r, find the appropriate conductor screen, press CTRL-C, up arrow, ENTER. This will reload the configuration.

I found determining how to create the images from the Fedora Atomic Cloud images a bit tedious. The diskimage builder tool would likely make this easier, if it supported RPM-ostree and Atomic.

Ironic needs some work to allow the pxe options to override the “root” initrd parameter. Ideally a glance image property would be allowed to be specified to override and extend the boot options. I’ve filed an Ironic blueprint for such an improvement.