Proposed Improvements for Custom Image Handling in MAAS

1- Intro

Based on these experiences with MAAS and the packer-maas solution, I’ve identified some areas where improvements could be made to enhance the user experience and functionality of MAAS, particularly in relation to custom image handling. I’ve outlined these proposed improvements below:

1.1- Refinement of the boot-resources create MAAS command parameters

The current name parameter could be split into two new parameters: os and os_identifier. This would provide a clearer distinction between the operating system type and its specific identifier. This could apply to other fields as well, I believe none should accept two values split by /.

For example:


os: ['ubuntu', 'ubuntu-core', 'bootloader', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']


os_identifier: ['ubuntu', 'centos', 'custom', 'rocky8', 'ol9', '???']

Similarly, the base_image parameter could be split into base_os and base_os_version. This would allow for more precise control over the base image selection.

For example:


base_os: ['ubuntu', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']


base_os_version: ['focal', '20.04', 'jammy', '22.04', 'rhel', 'custom', '???']

The boot-resources create command would then look something like this:

maas admin boot-resources create \
    os='custom' \
    os_identifier='myos1' \
    base_os='ubuntu' \
    base_os_version='jammy' \
    title='MyOS 1.0' \
    architecture='amd64/generic' \
    filetype='tgz' \

1.2- Clearer Guidelines for Creating and Using Different Image Types

Having well-defined instructions for creating and using different types of images in MAAS (i.e., the images used during transitioning stages such as Ephemeral, Commissioning, and Deploying) would be beneficial. This would help users to better understand the process and avoid potential issues.

1.3- Simplification and Redesign of Image Handling in MAAS

Currently, MAAS distinguishes between “official images” and “custom images”, as well as between “custom Ubuntu” and “custom non-Ubuntu” images. This classification could be reconsidered to simplify the image-handling process and make it more straightforward.

The operating system contained in the image should not significantly impact how MAAS handles it. Instead, the user could specify the base_image option, and MAAS could then select the appropriate provisioning script (like Preseed, Autoinstall, or Kickstart) based on this information. This could potentially make it easier to add Debian support to packer-maas. For instance, if a user passes base_image=ubuntu/jammy, MAAS could automatically select Autoinstall. This approach would make the image-handling process more flexible and user-friendly.

Another potential improvement would be the addition of custom Ephemeral O.S. images. For example, if a user plans to deploy CentOS 9 on a machine, the commissioning could also be done with a CentOS 9 Ephemeral O.S. This redesign could potentially simplify the image handling process and improve the overall user experience in MAAS.

1.4- Learning from Other Projects: Foreman and Ironic

MAAS developers could potentially gain valuable insights from examining how other projects, such as Foreman and Ironic, handle diverse images in their systems, including discovery, provisioning, inspection, and more.

For instance, in Foreman, the creation of an operating system and the association of provisioning templates can be done using the hammer CLI tool. Here’s an example:

# Create a new operating system
hammer os create --name "CentOS 9" --major 9 --architectures "x86_64" --family "Redhat"

# Associate provisioning templates
hammer template add-operatingsystem --name "Kickstart default" --operatingsystem "CentOS 9"
hammer template add-operatingsystem --name "Kickstart default finish" --operatingsystem "CentOS 9"
hammer template add-operatingsystem --name "Kickstart default PXELinux" --operatingsystem "CentOS 9"

In this example, a new operating system “CentOS 9” is created and associated with the necessary provisioning templates.

In Ironic, the handling of operating system images is done through the use of image properties. Here’s an example:

# Create a new image
openstack image create --file centos9.qcow2 --disk-format qcow2 --container-format bare --public centos9

# Set image properties
openstack image set --property os_distro='centos' --property os_version='9' centos9

In this example, a new image “centos9” is created and the necessary image properties are set.

By examining these and other aspects of Foreman and Ironic, MAAS developers could potentially find new ways to improve the handling of diverse images in MAAS.

Having explored MaaS 3.4, I’m excited to see that it now allows the selection of a custom image during the “Deployment” transitional stage (as shown in the attached screenshot #1), and also supports cloud-init. This means that all my requirements can now be implemented!

However, I’m still unsure about how to change the Ephemeral O.S. for the “Commissioning” stage, as the uploaded Custom O.S. doesn’t appear as an option (see attached screenshot #2). Let me elaborate on my idea.

My goal is to upgrade firmware (EFI, RAID, etc), and possibly pre-configure the hardware RAID volumes, either before or during the “Commissioning” stage. This way, MaaS would display the most recent versions and available volumes for machines in the “Ready” state.

Now that we can select a “Custom O.S.” for the “Deployment” stage (refer to the screenshot #1), I could perform these tasks during “Deployment” and then let MaaS complete the deployment on a fully-updated and pre-configured hardware RAID. However, it seems more appropriate to avoid such tasks during the “Deployment” stage, don’t you think?

I’m also considering configuring all hardware RAID during cloud-init, but performing firmware upgrades during the “Commissioning” or “mid-Deployment” stages with a “Custom O.S.”. However, if I configure the storage volumes via cloud-init at the end of the “Deployment” stage, MaaS might not properly recognize them, leading to inconsistencies.

In a previous post, I discussed similar solutions that now seem achievable with the custom “Deployment” image and cloud-init (Proprietary Firmware Upgrades and Hardware-RAID Layout Setup in MaaS 3.4). I also suggested a two-staged “Commissioning” process, where the first stage would be the current default in MaaS, and a second “Commissioning” process would perform the firmware upgrade using proprietary tools from various vendors.

Regarding the Ephemeral O.S., I’m considering creating a custom Ephemeral image using this project: lp:maas-images : Git : Code : maas-images. Is there a plan to migrate this to packer-maas? This would allow a single “Commissioning” stage, but with all the necessary tools in place, MaaS could perform the required firmware upgrades using proprietary tools, as fwupdmgr doesn’t support all available firmware.

I hope this clarifies my ideas and I look forward to your feedback.

Screenshot #1:

Screenshot #2:


1 Like