Comment 21 for bug 1899487

Revision history for this message
Brett Holman (holmanb) wrote :

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