Comment 26 for bug 1899487

Thanks @Alexander @Frode @Artom and @Slawek && Brett for weighing in on this long-standing bug and trying to sort long-term maintenance/migration use-cases and how cloud-init could better interact in those changing conditions/settings with neutron.

> @Slawek "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?"

I think that suggestion would work only for immediate deployment needs at initial deployment time. The other gap or issue is during long-term maintenance what an admin should do when changing MTU in Neutron or migrating OVS -> OVN and needs to trigger a network config refresh from cloud-init.

> But that don't solves anything because cloud-init already configured it during [first boot] boot process and will not check it again.

Correct, cloud-init by default won't perform any network config operations after first boot on OpenStack unless the configuration was added to /etc/cloud/cloud.cfg.d/80-some-file.cfg as Brett mentioned in #21.

Per Frode's comment #23: "the proposed workaround is only effective if you know about this situation beforehand."

Agreed. But, in the cases where an admin is changing an MTU value through Neutron or migrating from OVS to OVN, I think those use-cases are ones where we now know ahead of time we'll be changing network configuration that may need to be re-written by cloud-init.

In these cases where we know our existing VM will soon contain stale MTU data, I think we can prime the cloud-init system in one of two ways:

Option 1. Configure cloud-init to regenerate network on every boot and trigger that reboot manually or automatically after MTU settings have changed

a. Brett's comment makes sense here. Add /etc/cloud/cloud.cf.g.d/80-openstack-network-per-boot.cfg to the affected VM prior to network migration or MTU change:

cat > /etc/cloud/cloud.cfg.d/80-openstack-network-per-boot.cfg <<EOF
# apply network config on every boot
updates:
  network:
    when: ['boot']
EOF

b. Make MTU change or perform OVS->OVN migration steps
c. Trigger a VM reboot after either MTU changed or migration operation is complete.

Option 2. Configure cloud-init to react to udev hotplug events (v. 21.3 or later) and re-render network on such udev events on the running system without reboot

-- Do we know if migration from OVS -> OVN results in add|remove udev events, a VM configured for cloud-init hotplug would automatically read and apply new network_data.json values upon receipt of that udev event?

If udev events occur along this migration path, we can:
a. Write config to enable cloud-init to react to network hotplug add|remove events
cat > /etc/cloud/cloud.cfg.d/80-openstack-network-hotplug.cfg <<EOF
# Allow datasource to regenerate network config on any udev hotplug events
updates:
  network:
    when: ['hotplug']
EOF

b. Restart the VM prior to MTU change or OVS->OVN migration which will start systemd cloud-init-hotplug.socket and cloud-init-hotplug.service on the system to listen for udev hotplug events

c. Make changes to MTU or OVS-OVN migration to trigger udev events which will re-apply network config

If migration or MTU changes don't result in udev events it is possible to manually 'fake' such a hotplug event to force re-rendering of network if still you have console/ssh access to the VM;

# get a current physical interface name on the system
PHYS_INTERFACE=`python3 -c 'from cloudinit.net import get_interfaces; print([i[0] for i in get_interfaces() if i[0] != "lo"][0])'`

# fake a hotplug add event on a known NIC physical interface triggering cloud-init to crawl and apply of network_data.json metadata
 sudo cloud-init devel hotplug-hook -s net handle --udevaction add -d ${PHYS_INTERFACE}