OpenStack helper can generate interface names that are too long for VLANs

[cardoe]

Bug report

Related to bug #4743, the helper code at

cloud-init/cloudinit/sources/helpers/openstack.py

Lines 738 to 740 in 2b7d963

	link_updates.append(
	(cfg, "name", "%%s.%s" % link["vlan_id"], link["vlan_link"])
	)

does not respect the maximum length size. When using OpenStack Ironic and using bare metal systems you'll get the kernel driver device names which can be quite long. During normal operation they get renamed down to shorter forms (ens prefix vs enp prefix). However when the helper runs the longer form is the only name is available.

Why this issue isn't seen more is the fact that the generation of VLAN info isn't happening by default in network_data.json per bug https://bugs.launchpad.net/nova/+bug/2091185 but we are working to remedy that. In testing this issue has cropped up. The workaround here is the fact that OpenStack does not support the name field in their scheme per the comments in but a human crafts their own network_data.json today when they use VLANs and often provide their own name.

Steps to reproduce the problem

Run cloud-init with the OpenStack helper consuming network_data.json without a name field on the physical NIC and use something like Broadcom which likes to make 14 character interface names.

Environment details

• Cloud-init version:
• Operating System Distribution: Ubuntu 24.04
• Cloud provider, platform or installer type: OpenStack

I wonder if it wouldn't be better to remove those lines that issue the rename?

[cardoe]

Looks like just removing the name in the VLAN case won't do the trick. Here's the same system built without a VLAN interface. You can see the names are still too long.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno8303: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether c4:cb:e1:bf:90:d4 brd ff:ff:ff:ff:ff:ff
    altname enp195s0f0
3: enp196s0f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 14:23:f3:f5:3b:a0 brd ff:ff:ff:ff:ff:ff
4: eno8403: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether c4:cb:e1:bf:90:d5 brd ff:ff:ff:ff:ff:ff
    altname enp195s0f1
5: enp196s0f1np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 14:23:f3:f5:3b:a1 brd ff:ff:ff:ff:ff:ff
6: eno3np0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether d4:04:e6:4f:87:84 brd ff:ff:ff:ff:ff:ff
    altname enp197s0f0np0
7: eno4np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether d4:04:e6:4f:87:85 brd ff:ff:ff:ff:ff:ff
    altname enp197s0f1np1

The generated netplan for that system is:

network:
    version: 2
    ethernets:
        enp196s0f0np0:
            addresses:
            - 192.168.0.143/24
            match:
                macaddress: 14:23:f3:f5:3b:a0
            mtu: 1450
            routes:
            -   to: 0.0.0.0/0
                via: 192.168.0.1
            set-name: enp196s0f0np0

And the network_data.json that was used for this is:

{
  "links": [
    {
      "id": "tap5913c248-71",
      "vif_id": "5913c248-717a-4f40-b732-20ea8a1f2a34",
      "type": "phy",
      "mtu": 1450,
      "ethernet_mac_address": "14:23:f3:f5:3b:a0"
    }
  ],
  "networks": [
    {
      "id": "network0",
      "type": "ipv4",
      "link": "tap5913c248-71",
      "ip_address": "192.168.0.143",
      "netmask": "255.255.255.0",
      "routes": [
        {
          "network": "0.0.0.0",
          "netmask": "0.0.0.0",
          "gateway": "192.168.0.1"
        }
      ],
      "network_id": "bbb95bbb-618c-41c3-b65a-a327ab1d8b7d",
      "services": []
    }
  ],
  "services": []
}