| 2016-07-22 19:43:10 |
Mathieu Gagné |
bug |
|
|
added bug |
| 2016-07-22 19:43:10 |
Mathieu Gagné |
attachment added |
|
network_data.json https://bugs.launchpad.net/bugs/1605749/+attachment/4705526/+files/network_data.json |
|
| 2016-07-22 20:05:00 |
Benjamin Navaro |
bug |
|
|
added subscriber Benjamin Navaro |
| 2016-08-11 15:13:35 |
Mathieu Gagné |
description |
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
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
iface eth0 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto eth1
iface eth1 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto bond0.602
iface bond0.602 inet static
netmask 255.255.255.248
address 2.2.2.13
vlan-raw-device bond0
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
iface bond0.612 inet static
netmask 255.255.255.248
address 10.0.1.5
vlan-raw-device bond0
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
[2] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L284 |
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:
1) 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.
2) The "auto" stanza is missing from bond and bond slave interfaces. Interfaces are never started/configured properly at boot.
3) Once 1) and 2) are fixed, it looks like cloud-init runs the network configuration again in dsmode=net and fails at multiple steps:
3.1) get_interfaces_by_mac is run once again and tries to detect all known mac addresses by listing all entries found in /sys/class/net/. At this point, the bonding is up and the file 'bond_masters' exists. This means '/sys/class/net/bond_masters/address' won't exist (because /sys/class/net/bond_masters is a file, not a directory) and get_interface_mac will throw an uncatched exception, aborting the configuration process.
3.2) Once 3.1) is fixed, configuration fails again later because once the bonding is configured, all slave interfaces will have their mac addresses updated so they are all identical. This means convert_net_json will fail at the "need_names" step and will throw this exception: "No mac_address or name entry for" because now the mac address of one of the physical interface isn't found.
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
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
iface eth0 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto eth1
iface eth1 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto bond0.602
iface bond0.602 inet static
netmask 255.255.255.248
address 2.2.2.13
vlan-raw-device bond0
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
iface bond0.612 inet static
netmask 255.255.255.248
address 10.0.1.5
vlan-raw-device bond0
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
[2] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L284 |
|
| 2016-08-11 15:17:22 |
Scott Moser |
cloud-init: status |
New |
Confirmed |
|
| 2016-08-11 15:17:24 |
Scott Moser |
cloud-init: importance |
Undecided |
Medium |
|
| 2016-08-15 21:08:04 |
Mathieu Gagné |
description |
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:
1) 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.
2) The "auto" stanza is missing from bond and bond slave interfaces. Interfaces are never started/configured properly at boot.
3) Once 1) and 2) are fixed, it looks like cloud-init runs the network configuration again in dsmode=net and fails at multiple steps:
3.1) get_interfaces_by_mac is run once again and tries to detect all known mac addresses by listing all entries found in /sys/class/net/. At this point, the bonding is up and the file 'bond_masters' exists. This means '/sys/class/net/bond_masters/address' won't exist (because /sys/class/net/bond_masters is a file, not a directory) and get_interface_mac will throw an uncatched exception, aborting the configuration process.
3.2) Once 3.1) is fixed, configuration fails again later because once the bonding is configured, all slave interfaces will have their mac addresses updated so they are all identical. This means convert_net_json will fail at the "need_names" step and will throw this exception: "No mac_address or name entry for" because now the mac address of one of the physical interface isn't found.
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
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
iface eth0 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto eth1
iface eth1 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto bond0.602
iface bond0.602 inet static
netmask 255.255.255.248
address 2.2.2.13
vlan-raw-device bond0
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
iface bond0.612 inet static
netmask 255.255.255.248
address 10.0.1.5
vlan-raw-device bond0
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
[2] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L284 |
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:
1) 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.
2) The "auto" stanza is missing from bond and bond slave interfaces. Interfaces are never started/configured properly at boot.
3) Once 1) and 2) are fixed, it looks like cloud-init runs the network configuration again in dsmode=net and fails at multiple steps:
3.1) get_interfaces_by_mac is run once again and tries to detect all known mac addresses by listing all entries found in /sys/class/net/. At this point, the bonding is up and the file 'bond_masters' exists. This means '/sys/class/net/bond_masters/address' won't exist (because /sys/class/net/bond_masters is a file, not a directory) and get_interface_mac will throw an uncatched exception, aborting the configuration process.
3.2) Once 3.1) is fixed, configuration fails again but for a different reason. It is because once the bonding is configured, all slave interfaces will have their mac addresses updated so they are all identical. This means convert_net_json will fail at the "need_names" step and will throw this exception: "No mac_address or name entry for" because now the mac address of one of the physical interface isn't found.
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
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
iface eth0 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto eth1
iface eth1 inet manual
bond_miimon 100
bond-master bond0
bond_mode 4
bond_xmit_hash_policy layer3+4
auto bond0.602
iface bond0.602 inet static
netmask 255.255.255.248
address 2.2.2.13
vlan-raw-device bond0
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
iface bond0.612 inet static
netmask 255.255.255.248
address 10.0.1.5
vlan-raw-device bond0
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
[2] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L284 |
|
| 2016-08-22 13:59:21 |
Scott Moser |
merge proposal linked |
|
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/303563 |
|
| 2016-09-12 20:50:16 |
Scott Moser |
cloud-init: status |
Confirmed |
Fix Released |
|
| 2016-09-12 21:03:38 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2016-09-12 21:03:49 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Fix Released |
|
| 2016-09-12 21:03:58 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-09-12 21:03:58 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2016-09-12 21:04:12 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-09-12 21:04:14 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2016-09-12 21:04:17 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-09-13 20:15:00 |
Chris J Arges |
cloud-init (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-09-13 20:15:02 |
Chris J Arges |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-09-13 20:15:09 |
Chris J Arges |
bug |
|
|
added subscriber SRU Verification |
| 2016-09-13 20:15:15 |
Chris J Arges |
tags |
|
verification-needed |
|
| 2016-09-17 02:33:55 |
Scott Moser |
tags |
verification-needed |
verification-done |
|
| 2016-09-22 17:34:08 |
Launchpad Janitor |
cloud-init (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-09-22 17:34:55 |
Chris J Arges |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-03-31 03:18:38 |
Tuan |
bug |
|
|
added subscriber Hironori Shiina |
| 2023-05-10 15:20:12 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2698 |
|
