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
name parameter could be split into two new parameters:
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
os: ['ubuntu', 'ubuntu-core', 'bootloader', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']
os_identifier: ['ubuntu', 'centos', 'custom', 'rocky8', 'ol9', '???']
base_image parameter could be split into
base_os_version. This would allow for more precise control over the base image selection.
base_os: ['ubuntu', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']
base_os_version: ['focal', '20.04', 'jammy', '22.04', 'rhel', 'custom', '???']
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.