Ironic 2020

2020 has been a turbulent year, let us see what it brought to ironic! Here is my recollection of the most important events in the ironic world, as well as new features and other changes.

Ussuri Taiga

The first release series of the year started back in 2019 - the happy year when the word corona associated with a crown or a beer. Sigh. Double sigh.

Anyway, a few things did happen in 2020, most notably:

FIPS 140-2

No, this is not a name of Elon Musks's new child, it is a US government standard describing appropriate encryption algorithm. As any government standard it's rather long and boring, but there is one aspect of significance for us: it hates MD5. As a result, Python in FIPS mode refuses to use MD5 hash for anything. Well, now most of ironic is MD5-free, and for our hash ring we offer alternative algorithms.


… is a person that has temporary access to a bare metal machine. We have added this concept to the API and provided an ability to write policies for lessees. Worth noting that ironic itself does not provide a leasing system… (Yet?) Anyway, check out the node multi-tenancy documentation to give it a try.

Node retirement

One day all of us (who survive covid-19) retire. I, for one, am planning to move to the Alps and make cheese. Nodes also retire. Starting with Ussuri it's possible to mark a node as retired so that it no longer gets deployed after the current deployment is torn down.

Target devices for software RAID

Software RAID has been implemented in ironic with a few substantial limitations. One of them used to be inability to specify which physical disks participate in which volumes. This was fixed in Ussuri with a physical disk selection syntax borrowed from root device hints.

Nuclear midcycle

Midcycle meeting in Geneva, Switzerland would be a highlight of the year even if all other in-person meet-ups had not been canceled (just check out these photos). Thanks to the warm reception by the CERN team we have been able to discuss many important topics, among them security improvements, deploy steps finalization and Redfish issues. See Ussuri midcycle notes for all topics and the meeting notes.

Victorious Victoria

Given everything goes on in the world, the V release did not feel like a victory despite bringing quite a few notable additions!

New release model

This change is so vast and important that it probably deserves a blog post of its own. Long story short, ironic has diverged from the standard OpenStack release cadence by establishing regular (3 times a cycle) releases with their own support branches. For example, during the Victoria time frame:

  1. 15.1 was released in July and bugfix/15.1 was created from it;

  2. 15.2 was released in August and bugfix/15.2 was created from it;

  3. 16.0 was released on October and stable/victoria was created from it (since this release coincided with the global OpenStack Victoria release).

The bugfix branches are relatively short-lived and only accept important bug fixes. This change adds value to intermediate releases (like 15.1 and 15.2 in this example) and make them more predictable, thus hopefully increasing adoption.

Additionally, a new web site was created to promote the standalone usage.

HTTP basic authentication

Ironic has supported stand-alone (== without OpenStack) usage for a long time, but the authentication story offered Keystone or nothing. Victoria changed the game: ironic and ironic-inspector now support HTTP basic authentication with a fixed list of users. This addition was immediately adopted by Bifrost; in the Wallaby release it will even default to using this authentication method.

Bifrost CLI

Bifrost has historically been an advanced tool: using it required invoking Ansible playbooks with a relatively large number of parameters. The new bifrost-cli was created to make Bifrost friendlier to beginners.

On top of that, Bifrost received support for TLS for services.

Ramdisk ISO boot

The ramdisk deploy interface was created earlier to enable HPC operators to execute their workload from a ramdisk without provisioning an image to the hard drive. In Victoria two important boot interfaces, ipxe and redfish-virtual-media gained an ability to boot ISO images rather than a kernel/ramdisk pair.

This feature caught attention of the OpenShift community because it allows integrating a 3rd party installer image with ironic. Specially for them a vendor API to eject a virtual CD was added to redfish-virtual-media.

Agent power interface

This somewhat advanced feature creates a limited ability to provision bare metal machines without having access to their BMC for power management. Targeted primarily at standalone users, the agent power interface uses ironic-python-agent to reboot machines.

In-band deploy steps

This year we finally managed to finish the split of the monolithic deployment procedure into more flexible deploy steps. In Victoria the deploy/cleaning ramdisk can provide in-band deploy steps to be executed at a certain point during deployment.

I'm definitely planning on a blog post next year to show case this amazing addition.

Ramdisk networking

Historically our service ramdisk (based on ironic-python-agent) assumed DHCP even if networking booting was not used (e.g. with virtual media). A new highly experimental feature allows providing a static network configuration to use during deployment or cleaning. It does come with some limitations, e.g. it's not compatible with all base operating systems, check the DHCP-less ramdisk documentation.

Ramdisk TLS

Lack of encryption between the deploy ramdisk and ironic has long been something we had to live with. Introduction of the virtual media boot finally gave us hope: it enabled a secure way to pass secrets to booted machines.

The first part of the TLS work landed in Victoria and included an automatic way to configure the ramdisk (ironic-python-agent) API to serve over TLS and inform ironic about the generated certificate.

The second part - accepting the ironic API certificate via a generated ISO - was also finished in 2020, but will be included in the first Wallaby release - 16.1.

iSCSI deploy deprecation

In a bit sudden move, we decided to get rid of the iscsi deploy in the Xena release cycle. Despite serving us pretty well in the early years, this deploy method has always been a source of confusing bugs. After filling in the last feature gaps between iscsi and direct deploy methods, we decided to deprecate the former and make the latter a new default.

Speaking of feature gaps, the direct deploy started supporting file:// images and got a more flexible image_download_source configuration.

Run-time configuration changes

A small and easy to miss enhancement: a whole bunch of configuration options are now mutable, i.e. can be changed without a restart.


The changes listed above are just a subset of numerous additions and improvements to ironic and its satellite projects, so my apologies to those, whose favorite items I missed! As you can see, despite all troubles, it has been a break-through year for ironic and its community. Let's do even better next year!


Comments powered by Disqus