We have been happily deploying a handful of custom centos7 images via MAAS for years, running a set of late commands in curtin_userdata_custom to finish off the builds.
Now we want to start deploying a serialized custom ubuntu image (i.e., each update will increment the image name’s build number). If imported as “custom”, this image will attempt to call curtin_userdata_custom and fail, because the late commands don’t match the os.
Are there any recommendations on how to handle this situation? If we import the custom ubuntu image as “ubuntu”, would that upset any code that expects an image of type “ubuntu” to be a stock image provided from images.maas.io? There doesn’t seem to be a (good) way to add a separate curtin_userdata_custom file for this new image, as the naming of the tempita template seems to imply I would have to add the resource name to the file, which I expect to change fairly often. Is there a good way to determine the os from within the curtin_userdata_custom file and fork late commands appropriately?
Failing any good ideas, I suppose I would have to create a handful of curtin_userdata_custom_amd64_generic_centosxxxx files to match the existing centos image names and convert the more generic curtin_userdata_custom file for the ubuntu images.
hey, @pjonason, nice to hear from you again,
I understand your concern about deploying a custom Ubuntu image via MAAS when you’ve been using custom CentOS images. Since the late commands in curtin_userdata_custom don’t match the new OS, it makes sense to handle this differently. With the clear understanding that I’m just the technical author, and I’m totally spitballing here, the following things come to mind as possibilities:
- Could you try importing the custom Ubuntu image as type “ubuntu” instead of “custom”? This would allow it to use the standard Ubuntu
curtin_userdata template instead of expecting curtin_userdata_custom. As long as your code doesn’t make strict assumptions about vanilla Ubuntu images, this might work.
- Another idea is to check the OS in curtin_userdata_custom and run different late commands accordingly. You could parse the
/etc/os-release file or use something like lsb_release -i to determine the OS. Then run apt, yum, whatever, as needed.
- Creating separate
curtin_userdata_custom templates for each OS might be an option, though more work. You could have curtin_userdata_custom_ubuntu, curtin_userdata_custom_centos7, etc.
I’d probably try either importing as type “ubuntu” or checking the OS in curtin_userdata_custom, as those seem like the cleanest approaches. Let me know if you have any other questions. Meanwhile, I’m encouraging my engineering team members to take a look at your question, also. It’s nice to have you considering Ubuntu as your OS of choice.
1 Like
We tried importing the image as type “ubuntu”, but it fails to deploy with the error
{“hwe_kernel”: [“ubuntu-jammy-test3 has no kernels available.”]
which seems to be based on this code that is trying to set HWE_KERNEL. So that about wraps it up for option 1.
We will move on to the other options.
I can figure out no good way to do conditionals inside the curtin script itself, so my workaround is to perform the conditionals inside the shell scripts that the curtin script calls. Not the most efficient solution, as I still need to download and run the shell scripts to simply exit for ubuntu images, but it does the job.
If anyone comes up with a better solution, I’m all ears. 
