thanks for checking in @r00ta
the logic is admittedly odd. We have a need for multiple overlapping subnets, say 172.1.0.0/24 for instance. We will have groups of machines that we want to put through MAAS workflows and these groups will be in the same 172.1.0.0/24 network. I know this is a-typical but it’s a hard requirement for our company.
As for how we assign IP’s to machines within our overlapping subnets we’d control that outside MAAS and provide just-in-time-cloud-init via REST call. Obviously static ips.
I can see the data model of MAAS and I can tell this is a problem. There is a unique key on table maasserver_staticipaddress
constraint maasserver_staticipaddress_alloc_type_ip_8274db4c_uniq
unique (alloc_type, ip)
and also …
create unique index maasserver_staticipaddress_discovered_uniq
on maasserver_staticipaddress (ip)
where (NOT (alloc_type = 6));
… so my thought for dealing with this limitation was to intentionally lose touch with the machine after deployment by having the netplan get modified as part of the cloud-init
We presently use USB devices with ubuntu auto install subiquity cloud init conf and that works fine for setting the network interfaces on the machines.
For MAAS adoption here, we’d put machines needing to go back through a commission/erase/deploy workflow back into MAAS (MAAS would do it’s ip management). Obviously, those machines would compete for ip space but that’s okay since we don’t expect to take lots of machines through the workflow at the same time.
thoughts?
As an update, I was able to learn that the userdata has to be in the region server for anything interesting to happen but now I’m struggling with the problem where, my custom userdata is causing a deploy failure and I have no way of diagnosing what failed since the machine shutsdown before I can see any logs. I was planning on simplifying the custom userdata and doing something less destructive to start with and build my way up.