MAAS should provide an easy way to add PPAs on a per-system or per-tag basis

Features
1

We ran into an issue that highlights this need in MAAS to ensure we are installing the correct packages for systems during deployments:

On Power8 w/ Trusty, KVM does not work. MAAS can successfully deploy Ubuntu on Power however, Trusty does not have the correct qemu versions and likely never will due to how much work would be involved in SRUing as well as the fact that the SRU would affect multiple platforms that don’t need the updated version.

SO, qemu and libs are provided via cloud-archive for Kilo on Trusty.

However, there is no easy way to add these things to a system.

The documentation on hacking curtin_userdata is spotty at best and in any case, that tends to apply across ALL nodes, not just some nodes, as MAAS still lacks the ability to really provide per-system curtin_userdata files.

Also, MAAS seems to lack any easy or obvious way to apply different PPAs and Repositories per system when necessary.

So we need some way to add PPAs to nodes either arbitrarily or based on some measure (Tag? Arch?)

That way we could specify “Add CloudArchive PPA to any PPC64 node, use standard Trusty for all others”. This will ensure that an openstack deployment across a heterogeneous cluster of nodes will provide the same experience regardless of system type.

** ANother idea could be to simply add the PPA across RELEASE, so we could say “Add the Cloud ARchive PPA to all Trusty installs, but not Precise” or more specifically: “Add the Kilo Cloud Archive to all Trusty installs and add the Icehouse archive to all Precise installs” or something of that nature.

2

So my bug was ignored on launchpad for several years, and so far it’s not really been acknowledged on discourse either.

So new use cases:
I have a very small number of systems that need to include external repos for deployment (nVidia developer repos to install CUDA libraries). Today, I have to manually add those to nodes individually after deployment. If I had this feature I asked for back then, I could add the nVidia repo to MAAS and then ONLY apply it to nodes that had a tag like “GPGPU”.

We also maintain two repos for certification tooling. A stable release PPA and a development/daily PPA. This would allow me to assign the dev PPA to one or two nodes for testing purposes while leaving all other nodes using the stable PPA.

3

@bladernr, coming in 2.9, you will have the ability to add cloud-init user-data immediately prior to deployment. here is my rather ham-handed “artists-rendition” of what it might look like:

Screenshot%20from%202020-07-14%2009-34-37
Screenshot%20from%202020-07-14%2009-34-37891×689 35.5 KB

Would this solve your problem?

4

@bladernr, i am curious about one thing, i probably just don’t see it: it sounds like you’re configuring PPAs on a per-system basis, and i’m not sure i understand why – if that’s what you’re saying! I mean, you could configure a repository and not use it? :slight_smile: help me out here?

5

Would this solve your problem?

In a very painful manner, I’d rather not have to manually enter that information every time I deploy a node. I currently work around this by doing all the PPA additions after the OS is deployed via SSH commands, but ultimately, what I’m after is probably tag related:

Configure $PPA in MAAS and link that PPA to a tag (for instance #GPGPU)
Assign #GPGPU to 3 nodes in my MAAS environment
Any time those are 3 nodes are deployed, $PPA is configured during deployment

If I’m launching 30 nodes in quick succession, I don’t really want to have to remember to copy/pasta user data into each one as I do so.

@bladernr, i am curious about one thing, i probably just don’t see it: it sounds like you’re configuring PPAs on a per-system basis, and i’m not sure i understand why – if that’s what you’re saying! I mean, you could configure a repository and not use it?  help me out here?

In the first use case, I may have 30+ nodes, but only two or three of them have GPGPUs installed, so it’s pointless to just blankely add the external nVidia developer repo to every node I deploy. It’s not necessarily costly to do so, but it’s messy and inelegant.

More commonly however is this:
We maintain a stable and development PPAs for certification tools If I need to test a new package build in the development PPA, I have to switch EVERY node to the development PPA because activating and deactivating PPAs or repos in general is universal, not granular.

So if I have 30 nodes, and want to only test a potentially broken package in the dev PPA, I have to change them ALL to the dev PPA for the length of that one deployment, whcih means any legitimate deployment work could fail because now “production” machines (e.g. ones I don’t intend to install development packages on) are getting their tooling from dev instead of stable.

So this would also allow me the ability to have, as an arbitrary example, 25 nodes that pull from the stable cert PPA and 5 nodes that pull from the dev cert PPA. Those 25 nodes could continue doing regression testing or whatever using the stable tools without problem and the remaining 5 could be consistently deployed from the dev PPA any time I need to test dev packages, package builds, etc.

OR I also sometimes build test packages in my own PPA, and it would be helpful to be slightly more granualr and temporarily attach my personal PPA to a single node so I can install packages from there, without disrupting deployments on any other node.

Yes, I could do all this by hand after deployment, but I’d prefer to let MAAS do this work in an automated and consistent fashion. Plus, having this configured pre-deployment means I am far more likely to get a pristine installation each time, rather than being concerned that there is any stale or conflicting data left over from installing a package from stable, then installing from dev overtop of it.

And as far as I am aware, as of today, it is impossible in MAAS to do this at the machine level.

6

This certainly makes sense as a feature. But I think it will have more chance of getting to the roadmap as part of an enhancement to the cloud-init feature that @billwear pointed to.

I agree that currently using cloud-init for your use case is not really useful. But we’ve talked about making it so that you can upload a cloud-init script to MAAS and have it being applied to machines with a certain tag on deploy.