I have a fleet of machines that will be running Ubuntu 20.04. These machines each have two network adapters. Also! I don’t want MAAS assigning the IP address (which I see it doing from experimentation).
Previously we were using USB drives and the subiquity(cloud-init) config to correctly configure both adapters on two different networks successfully but now that I’m using straight cloud-init I’m not having any luck with the cloud-init “network>>ethernets>>addresses”
Does anyone care to share a functional example of providing cloud-init at deploy time that changes the network?
I see where MAAS is hogging the networking… /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg
that’s got the ip address that I don’t want MAAS using.
so I’m looking to completely subvert that.
When I put my test machine through the cycle I did not get that file created
/etc/cloud/cloud.cfg.d$ ls -ltr
total 28
-rw-r--r-- 1 root root 167 Oct 24 14:53 README
-rw-r--r-- 1 root root 2070 Oct 24 14:53 05_logging.cfg
-rw-r--r-- 1 root root 81 Jan 3 21:05 90_dpkg.cfg
-rw------- 1 root root 320 Jan 3 21:05 90_dpkg_maas.cfg
-rw-r--r-- 1 root root 364 Jan 3 21:05 90_dpkg_local_cloud_config.cfg
-rw-r--r-- 1 root root 35 Jan 3 21:05 curtin-preserve-sources.cfg
-rw-r--r-- 1 root root 295 Jan 3 21:06 50-curtin-networking.cfg
so,… back to making guesses about how this works.
I will try the region server next perhaps.
maybe after that I’ll stop assuming that maas respects the contents of /var/snap/maas/current/preseeds/ and do one of those overlay tricks to force it?
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
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.
First, you might want to set the IP mode of the boot interface of the machine to DHCP so that MAAS will use just one IP to PXE boot the machine and will not assign any static IP to the machine in the first installation.
Then, when you deploy the machine, you can use a cloud-init script like
#!/bin/sh
cat <<EOF > /etc/netplan/50-cloud-init.yaml
network:
ethernets:
enp5s0: // THE INTERFACE
addresses:
- 12.0.1.240/24 // WHATEVER IP ACCORDING TO YOUR LOGIC
match:
macaddress: 00:16:3e:4a:03:01 // WHATEVER MAC ADDRESS OF THE MACHINE
mtu: 1500
set-name: enp5s0
version: 2
EOF
netplan apply
creating that file and running netplan apply is something that’s happening at the tail end of cloud init?
It looks like it’s similar to a combination of
write_files:
- path: /etc/netplan/50-cloud-init.yaml
content: |
... all that stuf in a netplan file ...
followed by a
runcmd:
- neplan apply
do I have that correct?
If so, then yea I was considering dropping the curtain mod approach and dealing with this requirement “out-of-band”
If that’s the suggested way of doing this then sure, yea I’ll do that. Probably less complicated.
If you use curtin you don’t have to run netplan apply.
If you use curtin you can create a file for each specific machine to override that file at the end of the installation. You can follow this guide Custom machine setup . This approach would work fine, but it sounds a bit hard to extend and to manage for your use case.
On the other side, if you use the approach I suggested, curtin will install the netplan config that configures the interfaces to use DHCP and only at the first boot the machine would run the custom cloud init script. This means that the first time you boot the machine
it will get an IP from the DHCP server
it will run the custom cloud init script and it will reconfigure the network interface
After that the machine will use your configuration. From any following reboot the machine will use your configuration immediately, it will not use the DHCP one.
