Integrating coreos-installer with Ironic

In OpenShift bare metal IPI 1 we're using the Metal3 and Ironic projects for provisioning bare metal machines that later become a part of the cluster. Historically, we were using binaries from the Red Hat OpenStack, including a deploy ramdisk 2 based on Red Hat Enterprise Linux 8. However, OpenShift itself uses CoreOS - a RHEL-based distribution built specifically for container deployments.

Several months ago I was tasked with migrating from the RHEL-based to a CoreOS-based ramdisk for Metal3, as well as using coreos-installer for the installation process.

This post explains how I created a CoreOS-based ramdisk and a custom deploy process for Ironic using a new hardware manager 3. I will not cover the complete solution, but will rather concentrate on how the extensibility and flexibility of Ironic can be used to fulfill similar tasks.

Prior reading:

Read more …

Bare Metal + Kubernetes = ♡

In this blog post, I'm talking about Metal3 (pronounced "metal-kubed"): a Kubernetes API and a cluster API provider for bare metal. I'll explain how and why it uses Ironic, and how you can use it to provision bare metal machines.

I assume that you are familiar with Kubernetes and the concept of Custom Resource Definitions (CRD). I also won't spend time explaining what cluster API is, there are enough good resources on this topic. I will only say that it's a way for Kubernetes to manage itself, in this case by provisioning (and deprovisioning) bare metal machines.

Read more …

Deploy steps tutorial

In this tutorial I'm showing how to create a custom deploy step for Ironic, how to build a ramdisk with in and how to use it when deploying a node.

Deploy steps are an answer to question "how do I run non-standard actions during deployment". Out-of-band steps run from your control plane and can talk to the BMC. More interesting for us are in-band steps that run from within the machine and offer nearly infinite opportunity for customization.

Today we'll create a solution for the following story:

As an operator, I would like to inject small files into the root partition of the final instance through the bare metal API.

There are, of course, numerous way of implementing it, cloud-init being probably the most popular. But we will concentrate on using a deploy step. The complete source code for this tutorial can be found here: https://github.com/dtantsur/ironic-inject-files/

Read more …

Ephemeral workloads with Ironic

In this post I'm presenting the ramdisk deploy interface, explaining how to use it to run ephemeral workloads and how to provide configuration data for them.

Ironic has been actively explored by the scientific community as a way to automate running calculations without incurring the costs of virtualization. This sort of workloads does not necessarily require installing anything on the machine's hard drive, which may instead be used for caching, swap or not used at all. The results are posted back via HTTP(s) or stored on a network share.

Read more …

Setting IPMI credentials: the history

Auto-discovery of bare metal nodes is a peculiar thing: everyone wants it in theory, but very few end up using it after facing the harsh reality. The truth is, there is not so much information you can discover by powering a machine on and booting a special ramdisk on it. I mean, oh, sure, we can collect literally thousands of various facts and runtime characteristics, but a few critical ones keep evading us. Specifically, BMC credentials. The very few facts ironic needs to be able to manage the machine. Oops.

In all fairness to hardware vendors, it's not very sensible to allow any user, even one with root access, to learn these critical bits of a hardware infrastructure. Not in the cloud era.

Two ideas appeared from numerous heated (and not so much) discussions, one great and one abysmal:

  • Introspection rules as a way to encode the logic of setting the credentials post-discovery.

  • Setting IPMI credentials during discovery.

Today we're talking about the latter.

Read more …