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?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899487
Title:
cloud-init hard codes MTU configuration at initial deploy time
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1899487/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
