In a situation where MaaS is the sole DHCP provider directly attached to the network, I’m seeing some inconsistency in the deployment of a “static” address.
A node I deployed last week was configured for DHCP, but a static assignment was added to the DHCP server on the Rack controller for that network. This was perfect, exactly what we want.
I deployed a half-dozen new nodes last night, and they were configured with entirely static configurations with no DHCP. However I did find that static entries were added to the local Rack controller/DHCP server exactly as before.
I saw an older topic were someone was advice to configure them for DHCP and then add a snippet for each one with the static assignment… this seems like a lot of manual maintenance for something that MaaS should be able to do with the information it has.
Questions:
Any idea why it configured one with DHCP and the remainder with a static config? Is this something about overlap with reserved blocks that I’m overlooking?
Wouldn’t it be simple to add “DHCP-static assignment” as a choice? The code is already there to modify the DHCP config…
This is not expected. You might have edited the interface of a deployed machine that was using AUTO-IP (it’s a known UI bug - you should not be able to edit the interfaces of a deployed machine).
The behaviour you described happens when you set an interface to use the AUTO-IP mode. In short, MAAS will set a static assignment on the DHCP server and will also configure the machine’s interface (using netplan for ubuntu for example) to use such static IP.
If you specify DHCP instead, MAAS will NOT set a static assignment on the DHCP server and will configure the interface to use DHCP.
If you want the MAAS DHCP server to assign a static IP to a specific machine interface based (for example) on the mac address, you have to supply the mapping with a DHCP snippet.
We are currently reworking the DHCP servers and its configuration and in one of the upcoming releases we are going to support the scenario you described.
I suspect your analysis is true. That one node was one where I flipped back and forth trying out different configuration settings in the UI, and I probably confused the database.
We don’t need to change address information, but we really need to manage DNS configuration settings via DHCP. Is there any mechanism to support this without manually maintaining the dhcp snippets for each and every machine?
I’m staring at the code right now. The network preseed code doesn’t appear overly complex. Would you be willing to accept a patch that adds an attribute that treats the config as static for everything else (dhcp server, etc), but writes out dhcp configuration for curtin network preseed?
If I understand the operations correctly, we want you to set up everything exactly the same as if we had chosen static configuration–the database, the static DHCP reservation, etc. But when we write the curtin network configuration to disk we will instead make it be dhcp in /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg. So it seems like a very small code change to add an attribute and only check for it in the NodeNetworkConfiguration class…
In 3.6 you will be to create static dhcp assignments. Meaning you can create a mapping between a mac address and an ip, and then configure the machine interfaces the way you prefer. If you use DHCP mode, the machine interface will be configured to use DHCP and the dhcp server will provide the IP you configured. If you use AUTO IP then the machine configuration will use that IP as static (still whenever that interface requests an IP with DHCP it will always use that IP).
Why are you looking at curtin and cloud init? IIUC You wanted to configure your machine interface to use dhcp and let the dhcp server to always provide the same IP you want. From 3.6 you get it out of the box, without the need to deal with curtin and cloud init
When MaaS 3.5 configures our nodes it uses curtin to write out cloud-init configs for the networking. Have you completely replaced this in 3.6? Wouldn’t that be a major version change?
$ ls -la /etc/cloud/cloud.cfg.d
total 44
drwxr-xr-x. 2 root root 4096 Jan 19 18:47 .
drwxr-xr-x. 4 root root 4096 Sep 23 19:15 ..
-rw-r--r--. 1 root root 2070 Dec 4 2023 05_logging.cfg
-rw-r--r-- 1 root root 212 Nov 25 19:03 50-cloudconfig-maas-cloud-config.cfg
-rw-r--r-- 1 root root 25 Nov 25 19:03 50-cloudconfig-maas-datasource.cfg
-rw-r--r-- 1 root root 238 Nov 25 19:03 50-cloudconfig-maas-reporting.cfg
-rw-r--r-- 1 root root 43 Nov 25 19:03 50-cloudconfig-maas-ubuntu-sso.cfg
-rw-r--r-- 1 root root 1174 Nov 25 19:03 50-curtin-networking.cfg
-rw-r--r-- 1 root root 167 Dec 4 2023 README
That did not change. I’d suggest to try 3.6 beta (you can already try the snap): look at subnets → address reservations and check if that covers you use case
I was assuming it wouldn’t change. So it leaves me curious why you said “without the need to deal with curtin and cloud init” … are they not the tools you use to deploy the DHCP configuration to Network Manager?
I guess there is a misunderstanding somewhere. I mean that you should be able to achieve what you want without you dealing with details such as curtin and cloud init. MAAS will still use the same stack behind the scenes, but with the new features you should be able to cover your use case with the capabilities provided out of the box. Did you have the chance to try 3.6?