Comment 25 for bug 1899487

I read through this bug today and here are my thoughts about it.
@Artom - Neutron allows to update mtu of the network through API. It may also happen that e.g. during the migration from OVS to OVN backend networks will be changed from e.g. vxlan to geneve and that will change their MTU as well. And this is reflected in the network's info returned from neutron.
Now IIUC the problem here is with e.g. case like:
1. New VM is boot and plugged to the network with mtu=1450
2. Cloud init in the vm got mtu=1450 from the nova metadata service and configures it in the netplan's configuration,
3. VM got other network configuration from DHCP - so far so good, all works fine,
4. MTU of the network has changed for some reason, if You check with neutron's API, new value will be provided, and it will be also updated in the DHCP service from Neutron
5. Because in the VM MTU value was configured in netplan's config based on the old data from metadata service (see point 2) now it's not updated from the DHCP.

I think that nova provides as mtu data from the network_info_cache so new value will be visible in the metadata after some time (few seconds in my tests) after it was changed in Neutron. But that don't solves anything because cloud-init already configured it during boot process and will not check it again.

@Frode: is my understanding correct? If yes, could the solution be to provide mtu value in the metadata ONLY if all subnets on port don't have dhcp enabled? And provide null otherwise?