On the flip side the presence of the MTU key in the OpenStack metadata
cannot be used as an indicator for intent from either the system or the
user that the DHCP server should not be providing the MTU either.
Looking at the commit that changed the behaviour in OpenStack the intent
of the original code was to always provide the MTU value in the metadata
regardless of network type, the fact that it showed as `null` was a bug.
Up until 2017 the default for the OpenStack controlled DHCP server was
to always provide an MTU. In 2017 the ability to control this behaviour
was removed and from that point onward it always provides an MTU.
The user has no way of influencing the contents of the OpenStack network
metadata, apart from downgrading to a 5 year old version.
I don't see an easy way of overriding cloud-inits default behaviour by
adding additional configuration through vendor data either.
Perhaps adding a cloud-init config stanza for how the OpenStack source
driver should interpret the presence of MTU in the network metadata
could be a path to retain compability with anyone relying on the current
behaviour and at the same time providing a way forward for everyone
else?
Meanwhile instances are configured to obtain an address dynamically but
stuck with a static value for MTU forever, and not being able to adjust
to changes being made to the environment without manual intervention to
individual instances.
** Changed in: cloud-init
Status: Incomplete => New
--
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
