Ironic provisions bare metal over PXE, IPMI and Redfish, and calls the plugins the drivers

An API and a set of plug-ins, not a hypervisor

Ironic is described in the README as consisting of an API and plug-ins for managing and provisioning physical machines in a security-aware and fault-tolerant manner, and it can be used with nova as a hypervisor driver, or as a standalone service.

The architecture is the point. Ironic is not a hypervisor, and it does not run the workloads. It is the thing that takes a physical machine from registered to deployed, and it is built as a service with an API and a driver layer so that the specifics of how a given machine is managed are pluggable.

By default it uses PXE and IPMI/Redfish to interact with bare metal machines. Some drivers, the Redfish ones among them, also support advanced features like leveraging HTTPBoot or Virtual Media based boot operations, depending on the configuration by the user.

The dependency question is where the design shows its age and its strength at once. Ironic supports vendor-specific plug-ins which may implement additional functionality, but the README notes that many vendors have chosen to focus on their Redfish implementations instead of customised drivers.

That is a real convergence. Redfish is a standard management interface, and once a vendor's out-of-band controller speaks it well, a generic Redfish driver covers most of what a bespoke driver would have done. The remaining vendor-specific plug-ins are for the things Redfish does not model.

The entry points tell you which parts of the stack are replaceable

The packaging metadata in pyproject.toml exposes the plug-in surface as entry points, and reading them is the clearest way to see what Ironic treats as swappable.

The console container, which is the mechanism for interacting with a machine's console during provisioning, has four implementations registered under the ironic.console.container group.

[project.entry-points."ironic.console.container"]
systemd = "ironic.console.container.systemd:SystemdConsoleContainer"
kubernetes = "ironic.console.container.kubernetes:KubernetesConsoleContainer"
container = "ironic.console.container.container:ContainerConsoleContainer"
fake = "ironic.console.container.fake:FakeConsoleContainer"

The systemd, kubernetes and container entries are three ways to reach a serial console in three different deployment shapes, and the fake entry exists so tests can run without a machine.

The DHCP group does the same for network boot.

[project.entry-points."ironic.dhcp"]
dnsmasq = "ironic.dhcp.dnsmasq:DnsmasqDHCPApi"
neutron = "ironic.dhcp.neutron:NeutronDHCPApi"
none = "ironic.dhcp.none:NoneDHCPApi"

Three choices there. dnsmasq for a small standalone deployment where Ironic runs its own DHCP. neutron to integrate with the OpenStack networking service when Ironic is part of a cloud. And none, for environments where DHCP is handled entirely outside Ironic, which is what you want when the network is already managed by something else.

The database migration backend is also an entry point, pointing at ironic.db.sqlalchemy.migration, with a comment in the file noting that the call requiring it is unnecessary and is marked for removal. Those comments in the packaging file are a small window into how the project is maintained, and they are the kind of thing you only see in a repository that has been worked on for years.

The database, the API and the pieces around them

Ironic is a stateful service, and the packaging shows what that means in practice. The requirements list SQLAlchemy at 1.4.0 or newer and alembic for migrations, plus the oslo.db library, and os-profiler for the profiler.

The oslo.* family dominates the dependency list, with oslo.config, oslo.context, oslo.db, oslo.log, oslo.messaging, oslo.policy, oslo.serialization, oslo.service, oslo.versionedobjects and others. That is the standard OpenStack shape: a shared set of libraries for configuration, logging, policy enforcement, messaging and service lifecycle, so that any OpenStack service behaves the same way in those respects.

Two entries in the list are worth noticing because they are not obvious. keystoneauth1 and keystonemiddleware are the identity libraries, which is where the security-aware part of the overview comes from: Ironic authenticates against Keystone and applies policy on its API. The other is sushy, which is the Redfish library, confirming that Redfish support is a first class path rather than a bolt-on.

The API itself is documented separately, with an API reference at the baremetal endpoint, and the project also maintains release notes and design specifications. The design specifications are the more interesting document for an engineer, because they are where the state machine and the resource model are described.

The repository top level shows the rest of the tooling: a devstack/ directory for a local development stack, a playbooks/ directory for deployment automation, redfish-interop-profiles/ for hardware compatibility data, zuul.d/ for the continuous integration jobs, an api-ref/ directory, and a tox.ini for running the test environments.

Where the deployment model is still Nova's, and where it is not

The README is unusually direct about the ways to use the service, and it names two projects built on top of Ironic.

It can be used with nova as a hypervisor driver, or standalone. That is the first design decision, and it is the one that determines how much of Ironic you end up owning.

As a Nova driver, Ironic is one component of a cloud: a user asks Nova for a bare metal instance, Nova calls Ironic, and the operator never talks to Ironic directly. As a standalone service, Ironic is the whole system, with its own API that operators and tools call. The first is a smaller commitment, the second gives direct control.

The README also notes that there are numerous ways to put Ironic to work in deploying a bare metal node, above and beyond asking Nova for a bare metal instance, or for asking Ironic to manually deploy a specific machine. And it points at Bifrost and Metal3 as related projects which seek to simplify the use of and interaction with Ironic.

That last sentence is the most useful signpost in the README. Both Bifrost and Metal3 exist because Ironic's own interface, while complete, is not small. Metal3 aims to bring bare metal provisioning to Kubernetes clusters through a pattern of Ironic deployments, and Bifrost aims to provide a simpler API on top of the same machinery. Neither replaces Ironic, and if your problem is one of those two shapes, going through one of them will save you a lot of interface work.

The licence, the Python floor, and the packaging build

Ironic is distributed under the terms of the Apache License, Version 2.0, with the full terms in the LICENSE file. That is the standard OpenStack licence and, for a service you run inside your own infrastructure, the obligations are the familiar permissive ones.

The Python requirement is explicit. requires-python is 3.11 or later, and the classifiers list Python 3.11, 3.12, 3.13 and 3.14, which tells you the project tracks new Python releases rather than sitting on an old one. The package is classified as Development Status 5, Production/Stable, and the intended audience is listed as Information Technology and System Administrators, which is a plain statement of who it is for.

The build is pbr based, with the build system requiring pbr 6.1.1 or newer and the backend set to pbr.build. There is also a setup.py that does essentially the same thing through setuptools.

setuptools.setup(
    setup_requires=['pbr>=6.0.0'],
    pbr=True,
)

Note the version field is dynamic in pyproject.toml, along with dependencies, which means the version comes from git rather than being written by hand. That is the pbr convention and it is why the repository has no GitHub releases to point at: the version is derived from the commit.

The one thing the packaging does not tell you is how to run it, and that is deliberate. The README does not give an install command or a configuration snippet. It points to the documentation at docs.openstack.org/ironic/latest, the API reference, the release notes and the design specifications, and it points at the source of truth at opendev.org, since this GitHub repository is a mirror of code maintained at opendev.org.

Where Ironic is the wrong tool

Two clear cases and one that depends on your hardware.

The first is scale of ambition. Ironic is a stateful provisioning service with its own database, its own API, DHCP integration, a console mechanism, an image handling pipeline and a policy layer. That is a considerable amount of software to run in order to deploy a few machines. If you need bare metal for a handful of hosts, a manual PXE boot with a scripted kickstart, or a vendor's own deployment tooling, will be less work.

The second is when you want the Nova experience without OpenStack. The README points at Metal3 and Bifrost as the projects that simplify interaction with Ironic, and for a Kubernetes shop or a smaller environment those are the sensible entry points rather than Ironic's bare metal API directly.

The third is hardware, and it is the one that decides most deployments. The Redfish convergence described in the README is a real trend, but the README also keeps vendor-specific plug-ins around, which is the evidence that some hardware still needs bespoke work. A machine whose out-of-band controller exposes only a partial Redfish implementation, or whose boot behaviour does not fit the deploy drivers, will need custom driver work, and that work is where bare metal projects lose their schedules. The redfish-interop-profiles/ directory in the repository is where the compatibility data lives.

One more practical point. Ironic provisions machines, and provisioning implies trust in the network the machines boot from and the image they boot. The security-aware framing in the overview is real, but it is a property of the whole system you assemble around Ironic, not of Ironic alone.

Editorial conclusion

Adopt Ironic if you have physical machines to provision and you want a service that handles out-of-band management, image deployment and power control with a policy-aware API, especially if you already run OpenStack. Do not adopt it if you only need to boot a handful of servers occasionally, since the operational weight of a stateful provisioning service with its own database and DHCP integration is substantial. Before you deploy, read the API reference and the design specifications, and check the Redfish driver and hardware type support for the exact machines you have, because driver coverage is where bare metal projects usually stall.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openstack/ironic on GitHub
4. Project website
5. README