Ephemeral workloads with Ironic

Configuring

The ramdisk deploy is configured the same way as other deploy interfaces:

[DEFAULT]
enabled_deploy_interfaces = direct,ramdisk

and can be set per node:

baremetal node set <node> --deploy-interface ramdisk

Starting with the Wallaby cycle, Bifrost enables the ramdisk deploy by default, and I will use it throughout this guide.

Boot interfaces

Another Ironic concept is boot interface, which specifies how exactly a ramdisk (either our service ramdisk or a user-provided one) gets to a node. Since boot interface implementations have a direct impact on booting ramdisks, not all of them support the ramdisk deploy or all its options. The two main implementations are:

• ipxe - uses iPXE to boot the ramdisk or an ISO via network.

• redfish-virtual-media - uses the Redfish protocol to attach a remote ISO as a virtual media. It will look as a normal CD drive to the operating system.

Deploying

First, nodes must be configured with the right deploy and boot interfaces. For iPXE:

baremetal node set <node> --boot-interface ipxe --deploy-interface ramdisk

For Redfish virtual media:

baremetal node set <node> --boot-interface redfish-virtual-media --deploy-interface ramdisk

The for each deployment you need to provide a link to the kernel and ramdisk. Using the file protocol:

baremetal node set <node> \
    --instance-info kernel=file:///httpboot/ramdisk.kernel \
    --instance-info ramdisk=file:///httpboot/ramdisk.initramfs \
    --instance-info image_source=file:///httpboot/ramdisk.initramfs

Using HTTP:

baremetal node set <node> \
    --instance-info kernel=http://<bifrost IP>/ramdisk.kernel \
    --instance-info ramdisk=http://<bifrost IP>/ramdisk.initramfs \
    --instance-info image_source=http://<bifrost IP>/ramdisk.initramfs

If you have an ISO image, provide only it:

baremetal node set <node> --instance-info boot_iso=http://<bifrost IP>/myimage.iso

In the end deploy as normally:

baremetal node deploy <node>

After a few seconds your node will become active and start booting your ramdisk of choice.

To clean or not to clean?

Automated cleaning normally runs before a node is first available for deployment and between deployments. While it's highly encouraged to leave cleaning enabled, it may not make much sense for ephemeral workloads. Starting with Ironic 16.1.0 (Wallaby) and soon-to-be-released ironicclient 4.5.0 (also Wallaby), it is possible to disable cleaning for a node:

baremetal node set <node> --no-automated-clean

and enable it back afterwards:

baremetal node set <node> --automated-clean

If you workloads leave any temporary data (or you're using an older Ironic), it's highly recommended to keep cleaning enabled. If the data is not sensitive, you can limit cleaning to only remove metadata (partitioning) in ironic.conf:

[deploy]
erase_devices_priority = 0
erase_devices_metadata_priority = 10

Config drives

Config drive is a file system (usually ISO 9660, the one used for data CD) that contains first-boot configuration. Bare Metal provisioning API accepts config drives either as a gzipped and base64 encoded blob or as JSON sources.

meta_data

This structure contains generic information about the instance. The most useful fields are:

• name (Glean) or hostname (cloud-init) - host name for the node. Ironic defaults name to the node name.

• public_keys - a dictionary with SSH public keys as values. They will be added as authorized keys for the root user.

Example:

{
  "public_keys": {
    "0": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIChPTEJpAcqEaz0u1m9HuGizxZkjl401Jyw2nEU7or3T dtantsur@bifrost.localdomain"
  },
  "name": "testvm2"
}

network_data

Network configuration. The exact capabilities differ between Glean and cloud-init, but both a capable of setting IPv4 addresses (Glean has only limited support for IPv6), configuring DNS and creating bonds.

Example:

{
  "links": [
    {
      "id": "port-023c6a90-1e4b-4e02-a119-131d8a729b60",
      "type": "phy",
      "ethernet_mac_address": "52:54:00:1f:79:7e"
    }
  ],
  "networks": [
    {
      "id": "network0",
      "type": "ipv4",
      "link": "port-023c6a90-1e4b-4e02-a119-131d8a729b60",
      "ip_address": "192.168.122.42",
      "netmask": "255.255.255.0",
      "network_id": "network0",
      "routes": []
    }
  ],
  "services": []
}

Ramdisk with a config drive

Adding a config drive to a ramdisk deployment is only supported for Redfish virtual media and works by attaching the config drive to a virtual USB slot (the hardware must have it, which is quite common).

If your hardware supports redfish-virtual-media boot, everything else works the same way as for normal deployments: either build an image with your config drive or make Ironic build it for you:

baremetal node deploy <node> --config-drive '{"meta_data": {...}, "network_data": {...}}'

Scripting

The deployment command becomes quite large for larger config drives, so you may script the deployment in Python instead. As a nice side effect, you'll be able to populate MAC addresses automatically.

Start with installing openstacksdk and following its instructions on populating the environment. For Bifrost it's enough to do:

source /opt/stack/bifrost/bin/activate
export OS_CLOUD=bifrost

Now you can create a connection and fetch the required objects:

# Using environment variables for connection parameters
conn = openstack.connect().baremetal
node = conn.get_node(node_id)
port = next(conn.ports(node=node_id))

Then build meta data and network configuration:

meta_data = {
    "public_keys": {
        "0": open(os.path.expanduser("~/.ssh/id_ed25519.pub"), "rt").read(),
    }
}

network_data = {
    "links": [
        {
            "id": f"port-{port.id}",
            "type": "phy",
            "ethernet_mac_address": port.address,
        }
    ],
    "networks": [
        {
            "id": "network0",
            "type": "ipv4",
            "link": f"port-{port.id}",
            "ip_address": ip,
            "netmask": "255.255.255.0",
            "network_id": "network0",
            "routes": []
        }
    ],
    "services": []
}

Finally, configure the node (we set boot and deploy interfaces just in case) and deploy it:

conn.update_node(
    node,
    boot_interface="redfish-virtual-media",
    deploy_interface="ramdisk",
    instance_info={"kernel": kernel,
                   "ramdisk": initramfs,
                   "image_source": initramfs},
)
conn.set_node_provision_state(
    node, 'active',
    config_drive={'meta_data': meta_data, 'network_data': network_data},
    wait=True, timeout=300,
)

A complete example script can be found here: https://gist.github.com/dtantsur/7e614963d48cd929ef39fa60c0b34a3d.

See it in action

This short demo (no sound) show-cases what I've just explained: