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
:
os: ['ubuntu', 'ubuntu-core', 'bootloader', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']
os_identifier
:
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
:
base_os: ['ubuntu', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']
base_os_version
:
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' \
content@=custom-ubuntu.tar.gz
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.