Hey folks!
I’ve been working with the packer-maas solution and found it to be an excellent tool for creating custom non-Ubuntu images. However, I’ve encountered some issues and ambiguities during my tests, particularly with the MAAS UI and the parameters name and base_image in the context of differentiating between “custom Ubuntu images” and “custom non-Ubuntu images”. I’m hoping to get some clarification and possibly suggest some improvements.
I’ll start with what works, then the issues I found, and potential ideas/suggestions.
1- The packer-maas ubuntu RAW (LVM) build works
1.1- The packer build:
cd ~/tmp/git/packer-maas/ubuntu
PACKER_LOG=1 make custom-ubuntu-lvm.dd.gz
1.2- And MaaS upload:
maas admin boot-resources create \
name='custom/ubuntu-raw' \
title='Ubuntu Custom RAW' \
architecture='amd64/generic' \
filetype='ddgz' \
content@=custom-ubuntu-lvm.dd.gz
The image custom-ubuntu-lvm.dd.gz can be deployed to machines on MAAS. However, it has hard-coded LVM, which doesn’t seem to be desirable as it could interfere with storage layout and file systems that can be created using the MAAS UI.
2- Both Rocky and CentOS Stream 8 & 9 were successfully deployed
2.1- The packer build:
cd ~/tmp/git/packer-maas/rocky9
PACKER_LOG=1 make
2.2- And MaaS upload:
cd ~/tmp/git/packer-maas/rocky9
maas admin boot-resources create \
name='custom/rocky9' title='Rocky 9 Custom' \
architecture='amd64/generic' base_image='rhel/9' filetype='tgz' \
content@=rocky9.tar.gz
The image rocky9.tar.gz can be deployed to machines on MAAS without any issues. This process introduced the base_image option to my attention. I’m curious about how it works, what are its accepted values, and its effect on the provisioning workflow.
NOTE: I’m looking forward to adding Oracle Linux 9 support as well! Since it seems the only sane solution after Red Hat mess around killing CentOS stable and locking access to their source RPM packages.
3- BUG REPORT: A value for name starting with custom/ubuntu-... brings a broken option on the Deploy page
As soon as the custom/ubuntu-raw (or any custom/ubuntu-blah) appears in MAAS, the Deploy page shows the Ubuntu Custom RAW twice, one under OS -> Ubuntu which fails, and another under OS -> Custom which works.
3.1- The OS -> Ubuntu / Release -> Ubuntu Custom RAW entry which fails:
3.2- The OS -> Custom / Release -> Ubuntu Custom RAW entry which works:
This issue, while seemingly easy to ignore, causes confusion and could lead to deployment errors.
4- BUG REPORT: The packer-maas ubuntu TGZ build fails to deploy
4.1- The packer build:
cd ~/tmp/git/packer-maas/ubuntu
PACKER_LOG=1 time make custom-ubuntu.tar.gz
4.2- And MaaS upload:
maas admin boot-resources create \
name='custom/ubuntu-tgz' \
title='Ubuntu Custom TGZ' \
architecture='amd64/generic' \
filetype='tgz' \
content@=custom-ubuntu.tar.gz
The image custom-ubuntu.tar.gz cannot be deployed to machines on MAAS. This also created more duplicated entries on the Deploy page. The image is available under both Ubuntu (which fails) and Custom (which partially works, I mean, MaaS UI seems to start the Deployment but then it fails in the end - while the RAW works).
5- Playing with name, base_image, and “custom Ubuntu images”
If I try to create a “custom Ubuntu image”, it will fail:
5.1- The packer-maas build works
cd ~/tmp/git/packer-maas/ubuntu
PACKER_LOG=1 time make custom-ubuntu.tar.gz`
5.2- It can be uploaded to MaaS as “MyOS 1.0”
maas admin boot-resources create \
name='custom/myos1' \
title='MyOS 1.0' \
architecture='amd64/generic' \
filetype='tgz' \
content@=custom-ubuntu.tar.gz
5.3- But the Deployment failed:
It was uploaded and synced to the Rack Controller. However, the deployment failed with the error:
Wed, 12 Jul. 2023 22:01:44 HTTP Request - /images/custom/amd64/hwe-22.04/myos1/no-such-image/boot-kernel
Wed, 12 Jul. 2023 22:01:44 Marking node failed - Missing boot image custom/amd64/hwe-22.04/myos1.
…about name='custom/myos1', it’s split in two with separator /. I think I got it. lol
5.4- Trying to fix it
So, after learning a bit more about the base_image parameter, I re-uploaded, this time like this:
maas admin boot-resources create \
name='custom/myos1' \
title='MyOS 1.0' \
architecture='amd64/generic' \
filetype='tgz' \
base_image='ubuntu/jammy' \
content@=custom-ubuntu.tar.gz
Now the Deployment is started (no MaaS UI error). However, it failed in the end (like described in item “4”).
But it seems that at least I figured out how to “tell MaaS” that a custom image is really a “custom Ubuntu”, with base_image='ubuntu/...', without using name='custom/ubuntu-...', right? It seems to avoid “BUG mentioned on item 3”.
6. Clarifying the Role of the name and base_image Parameters
In my exploration of the name and base_image parameters, I’ve noticed some characteristics that could benefit from further clarification. These parameters seem to have a “dual role”, with their value being split by a /. This can be somewhat confusing, for example, as the second part of the name value appears to be more than just an identifier or label. For instance, if the name is set as custom/ubuntu, it seems that the base_image=ubuntu/jammy is not necessary, because the /ubuntu part of the name already informs MAAS that it’s a “custom Ubuntu” image.
An example of this can be seen in the error custom/amd64/hwe-22.04/myos1 mentioned in item “5.3”. This gives the impression that the second part of the name value has a significant impact on how MAAS interprets the image.
When I tried using name=myos1/..., it failed and presented the accepted values, revealing the accepted operating systems:
cd ~/tmp/git/packer-maas/ubuntu
maas admin boot-resources create name='myos/ubuntu-tgz' title='Ubuntu Custom TGZ' architecture='amd64/generic' filetype='tgz' content@=custom-ubuntu.tar.gz
Return error:
{"name": ["Unsupport operating system myos, supported operating systems: ['ubuntu', 'ubuntu-core', 'bootloader', 'centos', 'rhel', 'custom', 'windows', 'suse', 'caringo', 'esxi']"]}
This experience indicates that the documentation could be enhanced by explicitly explaining the dual role of the name parameter and providing a straightforward table of accepted values for both name and base_image. The aim is to avoid confusion caused by a single parameter that accepts two values split by a slash (/). While this information may already be documented, it’s not immediately clear or easy to find. Therefore, making this information more easily discoverable and understandable to users would be beneficial.
Cheers!
