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…
However I did find that static entries were added to the local Rack controller/DHCP server exactly as before.