RFC: Support provisioning with bootable images

Development RFCs
1

Hi,

I want to share my idea of supporting provisioning with bootable ISOs in Foreman. I recently gave a presentation at CfgmgmtCamp 25, but I’d like to share the concept here as well.

Introduction

The boot image, also known as bootable ISO or netboot media, is used for system installation from other sources, such as HTTP endpoint, CDN, or the Foreman itself. Operating systems that can be booted & installed from such an image are Fedora, CentOS Stream, Rocky, Alma, RHEL, and others.

The Foreman’s role in the process can be as simple as providing the content (with Katello) and Kickstart configuration for provisioning or, more complex, involving downloading and customizing the netboot images.

I want to vote for the latter option, as it provides a better end-to-end user experience.

Use case

This is what you can do with the current latest version of Foreman.

  1. The user downloads the netboot ISO from the internet.
  2. Using the mkksiso tool, customize the ISO to use Foreman for the content and the kickstart template.
  3. Create a host in the Foreman (in build mode)
  4. Boot host machine from the ISO
  5. Get the machine up and ready

Not great, not terrible. We can make it better.

  • Foreman can take care of the download.
  • Foreman can customize the ISO.
  • We can add logic where users don’t have to create a host before the provisioning process.
  • We can implement a logic similar to that of Discovered hosts.
  • And more. All that is done via the UI or API (hammer).

Implementation

The feature’s core is a tool called mkksiso, which is part of the Lorax package. With the mkksiso tool, we can easily customize the image, adding our config files for the Grub2, including kickstart (if needed), or even adding files, like certificates, allowing secure connections to Foreman from the start.

All the logic would be a Foreman Plugin, where we could utilize Foreman Tasks for the image jobs (download and customize). The plugin itself won’t be just one provisioning method; it can be extended with other methods, opening options for the future where we might move all the provisioning logic to the plugin.

Note: I’ll post a separate RFC about the plugin idea; I bet there’ll be a rich discussion about it.

Result

With the implementation described above, the end-to-end user scenario could look like this:

  1. In Foreman, the user will create a netboot ISO resource, defining a URL or path to the ISO image, name, and OS to associate with.
  2. Foreman will download the “base” iso to the drive.
  3. The user will then generate the customized iso. This includes:
  4. Add cert files to the iso.
  5. Updated Grub2 config file
  6. Kickstart file (or URL to the Foreman or Smart Proxy)
  7. …
  8. Foreman provides the URL where the user can download the file.
  9. Boot the VM from the iso.
  10. Machine call Foreman for kickstart
  11. If the host is in build mode, provide a kickstart.
  12. If not, show a message about it and wait until the host is ready for provisioning.
  13. Once prepared, continue with provisioning
  14. Get content from the Katello.
  15. Profit

Discovery image & bootdisks

Why introduce another method when we already have (multiple) Foreman Bootdisks and Foreman Discovery Image? Why add more stuff to the pile?

The reasons are simple.

  • The netboot iso is already there and is a way to install OS.
  • Multiple OSes support it.
  • Built and tested by the community.
  • Maintenance costs.

Summary

We have tools and ISOs maintained and tested by the community and supported by various operating systems. They are already there. It would benefit our users to have support for it.

2 Likes