cloud-init fails to configure bond interfaces from network_data.json
There is a couple of reasons:
Bond links found in network_data.json do not have a name attribute. cloud-init doesn't require the name attribute to exist in links. [1] However cloud-init later expects the links to have a name attribute and crashes when it doesn't have any. [2] The name attribute is not part of the OpenStack network_data.json specification and will therefore never be provided.
If a link name is provided, the generated ENI configuration has a couple of issues:
* cloud-init currently thinks that the bond_links attribute found in a bond link are actual physical interface names and not link id as expected.
This means you end up with 4 physical interfaces configured on the server: 2 existing physical interfaces (ex.: eno1 and eno2) and 2 physical interfaces based on the name found in bond_links (in that case, eth0 and eth1). The later don't exist on the server and configured bond interface tries to enslave non-existing links and fails to bring up.
* The "auto" stanza is missing from bond and bond slave interfaces. Interfaces are never started/configured properly at boot.
Here is attached to this bug a network_data.json for test purpose.
For reference, here is the MAC address mapping on the server:
- eno1: 0c:c4:7a:34:6e:3c
- eno2: 0c:c4:7a:34:6e:3d
Current rendered ENI is:
auto lo
iface lo inet loopback dns-nameservers 1.1.1.191 1.1.1.4
cloud-init fails to configure bond interfaces from network_data.json
There is a couple of reasons:
Bond links found in network_data.json do not have a name attribute. cloud-init doesn't require the name attribute to exist in links. [1] However cloud-init later expects the links to have a name attribute and crashes when it doesn't have any. [2] The name attribute is not part of the OpenStack network_data.json specification and will therefore never be provided.
If a link name is provided, the generated ENI configuration has a couple of issues:
* cloud-init currently thinks that the bond_links attribute found in a bond link are actual physical interface names and not link id as expected.
This means you end up with 4 physical interfaces configured on the server: 2 existing physical interfaces (ex.: eno1 and eno2) and 2 physical interfaces based on the name found in bond_links (in that case, eth0 and eth1). The later don't exist on the server and configured bond interface tries to enslave non-existing links and fails to bring up.
* The "auto" stanza is missing from bond and bond slave interfaces. Interfaces are never started/configured properly at boot.
Here is attached to this bug a network_data.json for test purpose.
For reference, here is the MAC address mapping on the server:
- eno1: 0c:c4:7a:34:6e:3c
- eno2: 0c:c4:7a:34:6e:3d
Current rendered ENI is:
auto lo
dns-nameserver s 1.1.1.191 1.1.1.4
iface lo inet loopback
iface eno1 inet manual
mtu 1500
iface eno2 inet manual
mtu 1500
iface bond0 inet manual
bond_xmit_ hash_policy layer3+4
bond_miimon 100
bond_mode 4
bond-slaves none
auto eth0
bond_xmit_ hash_policy layer3+4
iface eth0 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
auto eth1
bond_xmit_ hash_policy layer3+4
iface eth1 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
auto bond0.602
vlan-raw- device bond0
iface bond0.602 inet static
netmask 255.255.255.248
address 2.2.2.13
hwaddress fa:16:3e:b3:72:30
vlan_id 602
post-up route add default gw 2.2.2.9 || true
pre-down route del default gw 2.2.2.9 || true
auto bond0.612
vlan-raw- device bond0
iface bond0.612 inet static
netmask 255.255.255.248
address 10.0.1.5
hwaddress fa:16:3e:66:ab:a6
vlan_id 612
post-up route add -net 192.168.1.0 netmask 255.255.255.255 gw 10.0.1.1 || true
pre-down route del -net 192.168.1.0 netmask 255.255.255.255 gw 10.0.1.1 || true
[1] http:// bazaar. launchpad. net/~cloud- init-dev/ cloud-init/ trunk/view/ head:/cloudinit /sources/ helpers/ openstack. py#L547 bazaar. launchpad. net/~cloud- init-dev/ cloud-init/ trunk/view/ head:/cloudinit /net/network_ state.py# L284
[2] http://