MAAS 3.1 introduces breaking changes for custom centos7 images

[Evan Sikorski]

THE PROBLEM:

MAAS 3.1 now expects the following:

1. The dnf command to exist, which is not part of the standard CentOS7 image.
2. Netplan to be installed as a package named netplan.io, which is not packaged for CentOS7

This caused all of our previous customer CentOS7 images to no longer deploy, because dnf was not installed, and the expected netplan.io package was not installed.

We are able to build a netplan RPM ourselves using the .spec file from the netplan git repo, but...

1. It default package name is netplan and not netplan.io which would fail the check
2. We cannot use the latest version of netplan as that requires dependencies that cannot be met on CentOS7
3. Python3 then has to be installed from EPEL in order to install netplan.
4. Technically we have to install dnf as well, as your code uses DNF instead of YUM

THE DOCUMENTATION:

The only mention of this breaking changes is found in the release notes here

"About configuring deployed machine networking

If you deploy a machine with a custom Ubuntu image, MAAS allows you to configure the deployed machine’s networks just like any other MAAS machine. If you create an interface and assign it to a subnet or static address, this will be reflected in the deployed machine.

For this reason, MAAS also does some initial diagnostics while installing the custom image. MAAS will warn you about a missing network configuration, by checking for cloud-init and netplan in the curtin images. MAAS won’t deploy machine with such images."

1. I feel this could have been more clearly documented for those that are using custom images impacted by the change.
2. I also don’t see this being mentioned in either of these two documents for building custom images

1. https://maas.io/docs/how-to-create-custom-images#heading--how-to-pack-a-rhel7-image-for-maas-deployment
2. https://discourse.maas.io/t/how-to-create-custom-images/5104/2

ARBITRARY CHECKS?

After deploying images with netplan built into them both with standard single-interface and bonded network configurations, it appears netplan was not even used.

When commenting out your checks for the netplan packages from preseed.py, and deploying older images without netplan installed, we discovered they also deployed without issues and *never used netplan to write their network configuration*

I also noticed that the vanilla centos7 image you provide in MAAS does not have netplan installed and, because it is not a custom image, does not check for netplan.

---

I originally posted about this on discourse, here: https://discourse.maas.io/t/maas-3-1-introduces-breaking-changes-for-custom-centos7-images/6109

[Camille Rodriguez (camille.rodriguez)]

Hi MAAS team,

How can this be a "low" priority ? This release breaks a feature that is available and supported by Canonical. I'm raising this as field-critical as we have several customers deploying custom images and this change forces us to apply a manual patch to the maas snap.

[Jerzy Husakowski (jhusakowski)]

Fix on 3.3, backport to 3.2 and 3.1.

[Camille Rodriguez (camille.rodriguez)]

Thanks for the fix @adam-collard ! Is there a timeline to have this backported in 3.1 ?

[Igor Gnip (igorgnip)]

This does not appear to be fixed in maas 3.2.7 when deploying debian or something 'else' whatever that might be.

validations
98-validate-custom-image-has-cloud-init
98-validate-custom-image-has-netplan.io
are still being run during maas deployment.

[Alan Baghumian (alanbach)]

The main issue is that Debian images would get categorized as Ubuntu during deployment, hence 99-validate-custom-image-has-netplan.io is invoked.

That pretty much leaves us the only option of baking netplan.io packages into custom Debian images - which in reality should not be needed only if Debian was officially supported.

[Igor Gnip (igorgnip)]

Test case for 'other linuxes' is just making sure response is not None.