Enterprise Linux 9 is already a bit long in the tooth. When do you think we can get support for this?
If the answer is “when someone contributes it” I’m happy to assist. Please point me at the relevant points. The most relevant docs I found were here https://maas.io/docs/reference-maas-scripts but they really aren’t specific around OS support. Clue me in such that I can adapt rhel8 without understanding the entire code base and I’m happy to contribute.
The answer “somebody” already did packer-maas/rhel9 at main · canonical/packer-maas · GitHub
Yes there is a packer image. But there are numerous places in the UI where one can select version 8 but there’s no option for RHEL version 9.
Could you elaborate more wdym? You have to build the image and upload it as a custom image. You should be able to select it once it’s uploaded. You might have to reload the UI after the upload
Yes, we have already uploaded the images, etc. But all variants of every OS are “custom” – whereas there is first-class support for CentOS 7, CentOS 8, etc. It would be really helpful if there were more top-level/first-class OSes such that we have have OS-family defaults instead of having to replicate 98% of the same information between every variant.
Just to summarize: you’d like to avoid calling them “custom” but rather you’d like to see them displayed as “RHEL” or similar.
Turning this into a feature request
Well, there’s also a related issue that’s likely one of documentation. I’ve found that there is very different behavior by curtin depending on the value of base_image, which appears to be entirely undocumented.
For the almalinux, rhel, etc custom images when we upload them we must specify base_image='rhel/...' or the curtin configuration fails.
So in general, support for RHEL images could use some much better documentation… which I’m willing to help contribute, but I’m not certain I know the answers. For example, I got it working by hacking around with the base_image values but I have no idea what they “should” be or what the logic is behind them.
TL;DR it’s hard to feel that RHEL9 is “supported” when it’s not possible to deploy an image without slamming into a number of undocumented things you must do before it will work. So when I say “support” I mean “would work without reading issues and code from the repo”
There is https://maas.io/docs/how-to-build-a-rhel-8-image . If the steps listed there are not working you can click on the button at the end of the document and propose changes. Contributions are more than welcome 
Well I wouldn’t bother updating instructions for an end-of-life OS. I’d prefer to spend my time on EL9…
And I can’t really propose what the docs should say, because I don’t know the correct answers to how base_image should be assigned/selected. That’s knowledge I don’t have…
The steps are the same, just replace rhel8 with rhel9
I’d really like to understand what the value actually means. Due to other references which said rhel/8 we tried and are using rhel/9 and it works successfully. What’s the difference between rhel/rhel8 and rhel/8 as the base image? What’s the difference for rhel/9 ?
I’m an engineer looking to understand the usage, not someone asking for a value to plug in without any care for why that value matters.
rhel/9 is what we call base_image and it’s required when you upload a custom image. A base_image is composed by <distro_name>/<release>. The distro_name must be ubuntu, rhel, esxi and similar, while version can be whatever you want until you are happy with the choice. The distro_name must be consistent with the actual content of the image because MAAS is not introspecting the image you upload and needs to know what’s the distro of the image from you.
In short, you can use rhel/9, rhel/rhel9, rhel/r00ta or rhel/whatever.
Thank you! That was my impression, but I really wanted to get a clear answer from maintainers that this was so rather than basing my efforts on what seemed to be…
I really appreciate it.
just fwiw, part of what initially confused me is that this “base image” isn’t actually an image we supply. I initially assumed it had to refer to an existing image. It seems more like custom_image_distro field doesn’t it? 
I see the point and I agree. As it’s currently in the contract of the API we can’t change it, but I’ll take this into consideration for the new API we are implementing. Thanks!
