I marked a machine broken, changed the network on an interface, and then marked it as fixed.
I’m running into issues where the machine has the wrong IP due to lingering netplan data.
I can see the new curtin data here: maas $PROFILE machine get-curtin-config $SYSTEM_ID
I’ve tried forcing cloud-init -d clean and cloud-init -d init but that doesn’t clear away the old curtin data.
How can I force this?
Configuration is sent to a machine during deployment. Once a machine is deployed no new configuration is sent to the machine. To get the new network configuration the machine must be redeployed. Alternatively you can manually reconfigure the machine.
Even if you manually reconfigure network interfaces, there’s so much that goes wrong.
For example, these test scripts all fail after changing the interface:
Unable to communicate to the MAAS metadata service after applying custom network configuration.
The MAAS dhcp leases pages shows the machine’s IP address as “Observed” which leads the user to think that the IP address was merely “seen” on the network. Which isn’t true, tcpdump shows MAAS handing out the IP during DHCP DORA.
And lastly, the VLAN being reported on the machine in MAAS is still incorrect.
I’m only marching down this path because for some reason I have a few machines with network that changed to “Unconfigured” and I’m not sure how. I’d like to get them back on track, and testing is showing this to be a train wreck…
The way network testing works is by booting into the ephemeral environment using DHCP. The script runner, scripts, and configuration are all downloaded using the basic DHCP config. Before the connectivity test runs the script runner applies the network configuration you specified for the machine. Once your network configuration is applied the script runner checks that it can still communicate with the metadata server. Connectivity to the metadata server is required as that is how both results are sent back and deployments are finalized. If the script runner can’t connect to the metadata server your network settings are reverted(in the ephemeral environment only) and that error is sent.
I would check the IP information in over the API(maas $PROFILE machines read). Its possible MAAS does have the state but there is a bug in the UI. If the state is lost it won’t effect deployed machines as the config has already been written.
In my opinion, MAAS does a really bad job in handling networking and is very rigid. Once you’ve deployed a machine, you can’t change the network settings without redeploying the machine.
You want to change the IP to static? Nope, redeploy
You want to change the static IP to something else? Nope, redeploy
You want to use another network? Nope, redeploy
You want to create a bond? Nope, redeploy
Why isn’t there a maas agent deployed to the machine and have it listen to changes from MAAS UI and apply the changes?
@mrdmn: MAAS is designed to view individual machines as components of a deployment model, rather than relying on any particular machine to be up at any given time. Computers break, resource needs evolve, and network requirements change, so MAAS allows you to easily re-deploy to the same machine (after fixing it or changing its configuration) or deploy to a new one. For these reasons – and because re-deployment is the easiest way to ensure a clean, well-understood setup – we do not allow network changes on-the-fly for deployed machines. It’s a conscious design choice, intended to preserve a reproducible environment that is cleaner and smoother.
I understand what you’re saying but there is nothing clean and smooth about this sentiment (IMO). Minor configuration changes, like IP addressing and VLAN assignments, are common and should not require someone to completely redeploy a machine in order for MAAS to reflect the ground truth of a system.
I really like MAAS, and I’m a big believer in open source, but I’m left feeling the same frustration as @mrdmn by the lock-in that MAAS forces upon you.
For me specifically, I had a machine that I depended heavily upon on my home network. I was unaware that this machine’s network configuration had changed to “unconfigured” at some point. Once that happened, I’m left trying to get the machine’s network configuration to be the same as before. On the machine itself, its fairly trivial thru netplan configs. However, I’m depending on MAAS for DHCP and DNS. Which leads me full circle back to the MAAS lock-in. You can’t just alter the MAAS bind and dhcp config files. There is heavy reliance on MAAS’s backend database for IP addressing. I tried poking around the database, and even making changes to it, but I quickly found that it wasn’t helping because I wasn’t triggering all the backend scripts to keep MAAS happy and congruent.
I ended up having to set the IP address statically on the machine, and statically in MAAS just to get things back to semi normal.
I digress…
I understand. Then maybe MAAS is not what I’m looking for.
What I want is some tool that will help me manage (install an OS remotely and manage DHCP and DNS) a set of machines in a couple of racks. Machines that will not change their roles all that often, but which might have different networking requirements along their lifetime.
I’m wiling to bet that I’m not in the minority here and that other people have a similar use case.
Anyway, I don’t want to start a rant on this thread and hijack it. I do appreciate the software and the effort put into it, it’s just that some decisions (especially around networking) are not well made IMHO.
