Canonical MAAS support

[garymm]

Feature Request

Add a Talos support to MAAS, which will make it much easier to install on bare metal machines.

Description

This would mainly consist of adding a template to https://github.com/canonical/packer-maas

[frezbo]

Talos 1.8 will support qcow images from Image Factory, so it should just work

[garymm]

According to this, MAAS requires explicit support for every type of OS. A qcow image doesn't seem to be enough. I could be wrong. https://discourse.maas.io/t/make-it-possible-easier-to-use-custom-immutable-operating-systems-like-talos/6396/4

[smira]

In that case, I guess the issue should be in the MAAS repository, and worked there?

I don't see what is missing on Talos side so far? Is there anything?

[garymm]

Someone needs to contribute the packer template. I filed an issue with MAAS but they closed it and said "contributions welcome, we're not going to do this", whereas I thought the Talos community / Sidero might be more motivated, hence filing in a place where I think it might attract attention. Obviously you can close this issue if you don't want to track this feature request on this repo.

[smira]

I don't want to close this issue, but I want to clarify that nothing is needed from Talos side, and whoever is familiar with MAAS can send their pull request.

Just for the record, Talos is natively PXE-bootable, including direct PXE boot from the Image Factory, so if someone wants to skip MAAS or any other solution, it works as well without any extra tools.

[vladimirfx]

It looks like harness the horses in the car... Talos is the car, while Ubuntu, RHEL etc is the wagons. Talos just not need horses like MAAS or something:

It boobs from anything (just dd bootable device, or PXE, or cloud-init etc...). Can be configured by myriad of methods. Just use it - batteries included.

[dekarl]

maas-packer is good for custom images of traditional full OS

When we (Markus and I) looked into installing Talos with MaaS we hit the following issues:

• MaaS recognizes a successful deployment when the new machine accesses it's own meta-data, e.g. via cloud-init, or custom support in machined calling node.end_deployment() at https://github.com/canonical/maas/blob/master/src/metadataserver/api.py#L1108
• to access the metadata endpoint to get user-data you need OAuth machine keys
• MaaS writes them to a diskdumped images by running Curtin on the PXE booted helper https://github.com/canonical/cloud-init/issues/5685#issuecomment-2342036576

The idea was to fiddle with the Talos image to provide minimal Curtin customization files that are basically no-op files thus disabling everything Curtin wants to do. https://curtin.readthedocs.io/en/latest/topics/curthooks.html#image-provided-curtin-hooks

Then let machined get keys from the files written by Curtin and pull Talos' configuration from user-data to bring up the node. But that was way over my head.

Maybe you can just install Ubuntu with a user-data script that pulls the Talos image and DDs it over itself. I'll try that later.

[smira]

Sounds like MaaS should be a platform in Talos terms, like AWS or VMWare, which implements network configuration, fetching user-data (machine configuration for Talos), doing any other calls back to the infrastructure. There are many platforms supported in Talos, and most of them are community-managed and supported, so adding MaaS there shouldn't be a big deal once there's someone who is interested in using Talos on MaaS.

But like @vladimirfx said, for Talos using MaaS might make less sense than for "big" distros like Ubuntu, as booting up is not an issue, and management is API-based.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.