© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
79ea94a
(Get the code!)
In our functional test we use Bionic images, and sure enough the netplan.yaml [9]
written there does _NOT_ include the MTU! The OpenStack Metadata source remains
the same [10].
Hmm, however it should be the same version of cloud-init in either Bionic or Focal tests. Is this a netplan change?
That's one side of the coin. In working to understand the "best path forward" I just want to make sure I'm following.
The controls in the OpenStack DHCP service are purely a "on/off" switch (`advertise_mtu`) about advertising MTU in the DHCP network details and not the control for what that setting is? The reason I want to make sure is because I'm always leery when there are multiple sources of possible truth that have to be sorted and if a user can bite themselves by changing an MTU value in one place but also another and which do you listen to/respect.
The actual value for the MTU is a Neutron setting and in theory, should be the same then from DHCP network data or by the provided network_data.json information?
In this case the pain point is that existing instances won't process the DHCP change of MTU properly because cloud-init has written out the netplan.yaml and even though DHCP comes in with a new setting cloud-init isn't triggered in any fashion to update its understanding of the world and write out a new compatible netplan.
The final nail in this coffin is that the setting cloud-init is setting overrides the value for MTU that comes in via DHCP.
Do I have that right? If so, a couple of questions then.
1. It seems it would be worthwhile to see if there was some method for a refreshing cloud-init's details on the network. Ideally here, changing the network data in Neutron would be able to trigger an update on instances, though that's a tricky can of worms that could lead to broken networking on existing hosts if it goes wrong. It smells a bit like the work we want to completed next cycle around allowing hotplug of a new nic/device and be able to help drive networking config for it...just without the whole new device thing heh.
2. Should the setting that cloud-init writes be an overwriting value in netplan? Could this be a bug that netplan is not allowing the dhcp details to be respected over what cloud-init started with?