Hi Alexander,
Thanks for reopening. Sorry to hear about the instance loss.
We have a short term fix, but I think we need to request a fix in
Openstack for network_data.json as well. Currently cloud-init passes a
configured MTU value to the renderers (netplan/systemd-networkd/etc),
which in turn treat a configured MTU as overriding DHCP MTU options.
There are reasons one might want to do this so I don't think we want to
try to change this behavior for all of cloud-init.
You can force cloud-init to configure the network on every boot[1], the
downside is that this will increase subsequent boot times.
To semantically match other datasources, Openstack would only expose MTU
settings if it intended for the MTU to override DHCP's MTU option. This
would mean that the mtu would only get configured if a link's network
type was not dhcp (change here[2] I think). Could you open a ticket with
openstack for this? If that would break other use cases, this behavior
could possibly be worked around in the cloud-init openstack datasource
by ignoring the MTU metadata field, but I would want to see if Openstack
can fix this first resorting to that.
[1] Override:
# apply network config on every boot
updates:
network:
when: ['boot']
[2]
https://github.com/openstack/nova/blob/261de76104ca67bed3ea6cdbcaaab0e44030f1e2/nova/virt/netutils.py#L266
--
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
