def get_custom_image_dependency_validation(node, base_osystem):
if node.get_osystem() != "custom":
return None
cmd = {}
err_msg = "not detected, MAAS will not be able to configure this machine properly"
deps = ["cloud-init", "netplan.io"]
for i, dep in enumerate(deps):
in_target = None
if base_osystem == "ubuntu":
in_target = 'dpkg-query -s {dep} || (echo "{dep} {err_msg}" && exit 1)'.format(
dep=dep, err_msg=err_msg
)
if base_osystem == "centos":
in_target = (
'dnf list {dep} || (echo "{dep} {err_msg}" && exit 1)'.format(
dep=dep, err_msg=err_msg
)
)
if in_target is not None:
cmd[
"{priority}-validate-custom-image-has-{dep}".format(
priority=98 + i, dep=dep
)
] = [
"curtin",
"in-target",
"--",
"bash",
"-c",
in_target,
]
return cmd
MAAS 3.1 now expects
The dnf command to exist, but CentOS7 came before yum was renamed to dnf. At the very least a symlink will be needed to allow this command to be executed, but this feels sloppy. Why couldnât there be a check for dnf OR yum?
Netplan to be installed as a package, but there is no RPM for netplan on CentOS7. The user would have to build and install their own netplan RPM in order to get past this
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.
This could have been more clearly documented.
I also donât see this being mentioned in either of these two documents
After installing dnf, python3, and a custom netplan rpm in our custom image we are able to deploy, howeverâŚ
netplan appears to never be used, so this is an arbitrary check for packages that are never used requires installing non-stock packages into centos7 custom images for no apparent reason.
It seems as if this was an intentional change which is why I posted this in documentation request, as there is really no other information about this other than the little burb in release notes.
yeah, our custom image expert wasnât sure about that, while other team members thought it might be an as-built thing â but we donât have a clear explanation of why we would have done this. hence i wanted a bug, so we can at least review it and decide if it changes doc or code. thanks for doing this.
@billwear no, I am referring to above reference that this should be filed as bug for 3.2. Urgency of fixing this for 3.1 is higher than urgency to release 3.2 donât you agree ?
so to be clear, i asked for a 3.2 bug so we could get the team to look at it. as a general rule, we donât support arbitrarily customised images (how could we, you could change anything?). removing dnf, for example, would be hard to support. weâre talking about this now (thanks for the bug, it raised awareness), but i canât really promise how we might address (or not address) this issue.
Does the out of the box centos7 have dnf, python3 and netplan ? No.
This means that it should be possibly (and was previously) to deploy without one and the change is very arbitrary.
I am currently not using custom centos images but this raises alarm as Canonical obviously does not build and support netplan rpms and somehow they became required.
The intent here is maybe to get some feedback on why was this change made, what are the benefits on it and when will the documentation be updated to reflect the change ?
