Activity log for bug #1682871

Date Who What changed Old value New value Message
2017-04-14 16:32:43 Scott Moser bug added bug
2017-04-14 16:37:10 Scott Moser cloud-init: status New Confirmed
2017-04-14 16:37:12 Scott Moser cloud-init: importance Undecided Medium
2017-04-14 16:51:08 Scott Moser attachment added btest-launch.sh https://bugs.launchpad.net/cloud-init/+bug/1682871/+attachment/4862136/+files/btest-launch.sh
2017-04-14 17:00:51 Scott Moser summary attempts to rename vlans / get_interfaces_by_mac does not filter vlans attempts to rename vlans / vlans have addr_assign_type of 2
2017-04-14 17:01:01 Scott Moser summary attempts to rename vlans / vlans have addr_assign_type of 2 attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4
2017-04-14 17:01:49 Scott Moser bug task added cloud-init (Ubuntu)
2017-04-14 17:02:03 Scott Moser cloud-init (Ubuntu): status New Confirmed
2017-04-14 17:02:25 Scott Moser bug task added linux (Ubuntu)
2017-04-14 17:02:41 Scott Moser linux (Ubuntu): status New Fix Released
2017-04-14 17:02:51 Scott Moser nominated for series Ubuntu Xenial
2017-04-14 17:02:51 Scott Moser bug task added linux (Ubuntu Xenial)
2017-04-14 17:02:51 Scott Moser bug task added cloud-init (Ubuntu Xenial)
2017-04-14 17:05:10 Scott Moser description When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. Related bugs: * bug 1669860: cloud-init attempts to rename bonds When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds
2017-04-14 17:05:14 Scott Moser linux (Ubuntu Xenial): status New Confirmed
2017-04-14 17:05:26 Scott Moser cloud-init (Ubuntu Xenial): status New Confirmed
2017-04-14 17:05:34 Scott Moser cloud-init (Ubuntu Xenial): importance Undecided Medium
2017-04-14 17:05:39 Scott Moser cloud-init (Ubuntu): importance Undecided Medium
2017-04-19 15:57:56 Dimitri John Ledkov description When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds [Impact] * When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen. * When underlying interface MAC address is changed, it does not propagate to the vlan interfaces. [Test Case] * Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0. * Update the base interface mac address, the mac address of the vlan interface should change too. [Regression Potential] * Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.6+ kernels. [Other Info] * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels commit 308453aa9156a3b8ee382c0949befb507a32b0c1 Author: Mike Manning <mmanning@brocade.com> Date: Fri May 27 17:45:07 2016 +0100 vlan: Propagate MAC address to VLANs The MAC address of the physical interface is only copied to the VLAN when it is first created, resulting in an inconsistency after MAC address changes of only newly created VLANs having an up-to-date MAC. The VLANs should continue inheriting the MAC address of the physical interface until the VLAN MAC address is explicitly set to any value. This allows IPv6 EUI64 addresses for the VLAN to reflect any changes to the MAC of the physical interface and thus for DAD to behave as expected. Signed-off-by: Mike Manning <mmanning@brocade.com> Signed-off-by: David S. Miller <davem@davemloft.net> * Original bug report When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds
2017-04-19 15:58:02 Dimitri John Ledkov linux (Ubuntu Xenial): status Confirmed Triaged
2017-04-19 15:58:04 Dimitri John Ledkov linux (Ubuntu Xenial): importance Undecided High
2017-04-19 15:58:11 Dimitri John Ledkov linux (Ubuntu Xenial): assignee Canonical Kernel (canonical-kernel)
2017-04-19 16:00:27 Dimitri John Ledkov attachment added 0001-vlan-Propagate-MAC-address-to-VLANs.patch https://bugs.launchpad.net/cloud-init/+bug/1682871/+attachment/4864939/+files/0001-vlan-Propagate-MAC-address-to-VLANs.patch
2017-04-19 16:12:46 Kleber Sacilotto de Souza bug added subscriber Kleber Sacilotto de Souza
2017-04-19 16:25:30 Dimitri John Ledkov attachment added vlans-steal-mac-addresses.patch https://bugs.launchpad.net/cloud-init/+bug/1682871/+attachment/4864966/+files/vlans-steal-mac-addresses.patch
2017-04-19 16:26:05 Dimitri John Ledkov description [Impact] * When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen. * When underlying interface MAC address is changed, it does not propagate to the vlan interfaces. [Test Case] * Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0. * Update the base interface mac address, the mac address of the vlan interface should change too. [Regression Potential] * Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.6+ kernels. [Other Info] * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels commit 308453aa9156a3b8ee382c0949befb507a32b0c1 Author: Mike Manning <mmanning@brocade.com> Date: Fri May 27 17:45:07 2016 +0100 vlan: Propagate MAC address to VLANs The MAC address of the physical interface is only copied to the VLAN when it is first created, resulting in an inconsistency after MAC address changes of only newly created VLANs having an up-to-date MAC. The VLANs should continue inheriting the MAC address of the physical interface until the VLAN MAC address is explicitly set to any value. This allows IPv6 EUI64 addresses for the VLAN to reflect any changes to the MAC of the physical interface and thus for DAD to behave as expected. Signed-off-by: Mike Manning <mmanning@brocade.com> Signed-off-by: David S. Miller <davem@davemloft.net> * Original bug report When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds [Impact]  * When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.  * When underlying interface MAC address is changed, it does not propagate to the vlan interfaces. [Test Case]  * Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.  * Update the base interface mac address, the mac address of the vlan interface should change too. [Regression Potential]  * Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels. [Other Info]  * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels commit 308453aa9156a3b8ee382c0949befb507a32b0c1 Author: Mike Manning <mmanning@brocade.com> Date: Fri May 27 17:45:07 2016 +0100     vlan: Propagate MAC address to VLANs     The MAC address of the physical interface is only copied to the VLAN     when it is first created, resulting in an inconsistency after MAC     address changes of only newly created VLANs having an up-to-date MAC.     The VLANs should continue inheriting the MAC address of the physical     interface until the VLAN MAC address is explicitly set to any value.     This allows IPv6 EUI64 addresses for the VLAN to reflect any changes     to the MAC of the physical interface and thus for DAD to behave as     expected.     Signed-off-by: Mike Manning <mmanning@brocade.com>     Signed-off-by: David S. Miller <davem@davemloft.net>  * Original bug report When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds
2017-04-19 16:28:14 Ubuntu Foundations Team Bug Bot tags patch
2017-04-20 10:12:16 Launchpad Janitor merge proposal linked https://code.launchpad.net/~xnox/cloud-init/+git/cloud-init/+merge/322828
2017-04-26 01:30:48 Launchpad Janitor cloud-init (Ubuntu): status Confirmed Fix Released
2017-05-03 22:04:33 Chad Smith description [Impact]  * When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.  * When underlying interface MAC address is changed, it does not propagate to the vlan interfaces. [Test Case]  * Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.  * Update the base interface mac address, the mac address of the vlan interface should change too. [Regression Potential]  * Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels. [Other Info]  * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels commit 308453aa9156a3b8ee382c0949befb507a32b0c1 Author: Mike Manning <mmanning@brocade.com> Date: Fri May 27 17:45:07 2016 +0100     vlan: Propagate MAC address to VLANs     The MAC address of the physical interface is only copied to the VLAN     when it is first created, resulting in an inconsistency after MAC     address changes of only newly created VLANs having an up-to-date MAC.     The VLANs should continue inheriting the MAC address of the physical     interface until the VLAN MAC address is explicitly set to any value.     This allows IPv6 EUI64 addresses for the VLAN to reflect any changes     to the MAC of the physical interface and thus for DAD to behave as     expected.     Signed-off-by: Mike Manning <mmanning@brocade.com>     Signed-off-by: David S. Miller <davem@davemloft.net>  * Original bug report When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds [Impact]  * When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.  * When underlying interface MAC address is changed, it does not propagate to the vlan interfaces. [Test Case]  * Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.  * Update the base interface mac address, the mac address of the vlan interface should change too. * cloud-init test case wget https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg; chmod 755 get-proposed-cloudimg; for release in xenial yakkety zesty; do ./get-proposed-cloudimg $release; MODE=vlan ./btest-launch.sh $release-server-cloudimg-amd64-proposed.img <LP_ID>; # ubuntu/passw0rd python3 -c 'from cloudinit.net import get_interfaces_by_mac; print(get_interfaces_by_mac())'; # results in no runtime error and doesn't report vlan interface name done [Regression Potential]  * Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels. [Other Info]  * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels commit 308453aa9156a3b8ee382c0949befb507a32b0c1 Author: Mike Manning <mmanning@brocade.com> Date: Fri May 27 17:45:07 2016 +0100     vlan: Propagate MAC address to VLANs     The MAC address of the physical interface is only copied to the VLAN     when it is first created, resulting in an inconsistency after MAC     address changes of only newly created VLANs having an up-to-date MAC.     The VLANs should continue inheriting the MAC address of the physical     interface until the VLAN MAC address is explicitly set to any value.     This allows IPv6 EUI64 addresses for the VLAN to reflect any changes     to the MAC of the physical interface and thus for DAD to behave as     expected.     Signed-off-by: Mike Manning <mmanning@brocade.com>     Signed-off-by: David S. Miller <davem@davemloft.net>  * Original bug report When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs:  * bug 1669860: cloud-init attempts to rename bonds
2017-05-05 14:01:34 Scott Moser nominated for series Ubuntu Yakkety
2017-05-05 14:01:34 Scott Moser bug task added linux (Ubuntu Yakkety)
2017-05-05 14:01:34 Scott Moser bug task added cloud-init (Ubuntu Yakkety)
2017-05-05 14:01:34 Scott Moser nominated for series Ubuntu Zesty
2017-05-05 14:01:34 Scott Moser bug task added linux (Ubuntu Zesty)
2017-05-05 14:01:34 Scott Moser bug task added cloud-init (Ubuntu Zesty)
2017-05-05 15:44:55 Scott Moser cloud-init (Ubuntu Yakkety): status New Confirmed
2017-05-05 15:44:57 Scott Moser cloud-init (Ubuntu Zesty): status New Confirmed
2017-05-05 15:45:00 Scott Moser cloud-init (Ubuntu Yakkety): importance Undecided Medium
2017-05-05 15:45:02 Scott Moser cloud-init (Ubuntu Zesty): importance Undecided Medium
2017-05-08 19:05:31 Steve Langasek cloud-init (Ubuntu Xenial): status Confirmed Fix Committed
2017-05-08 19:05:36 Steve Langasek bug added subscriber Ubuntu Stable Release Updates Team
2017-05-08 19:05:42 Steve Langasek bug added subscriber SRU Verification
2017-05-08 19:05:49 Steve Langasek tags patch patch verification-needed
2017-05-11 20:20:57 Chad Smith tags patch verification-needed patch verification-done-xenial verification-needed
2017-05-11 20:30:37 Steve Langasek cloud-init (Ubuntu Yakkety): status Confirmed Fix Committed
2017-05-11 20:37:30 Steve Langasek cloud-init (Ubuntu Zesty): status Confirmed Fix Committed
2017-05-12 13:27:02 Kleber Sacilotto de Souza linux (Ubuntu Xenial): status Triaged In Progress
2017-05-12 13:55:43 Kleber Sacilotto de Souza linux (Ubuntu Yakkety): status New Fix Released
2017-05-12 13:55:48 Kleber Sacilotto de Souza linux (Ubuntu Zesty): status New Fix Released
2017-05-12 19:15:34 Chad Smith tags patch verification-done-xenial verification-needed patch verification-done-xenial verification-done-yakkety verification-done-zesty
2017-05-16 13:07:08 Kleber Sacilotto de Souza linux (Ubuntu Xenial): assignee Canonical Kernel (canonical-kernel) Kleber Sacilotto de Souza (kleber-souza)
2017-05-17 02:58:17 Launchpad Janitor cloud-init (Ubuntu Xenial): status Fix Committed Fix Released
2017-05-17 02:59:03 Chris Halse Rogers removed subscriber Ubuntu Stable Release Updates Team
2017-05-17 03:07:38 Launchpad Janitor cloud-init (Ubuntu Yakkety): status Fix Committed Fix Released
2017-05-17 03:14:07 Launchpad Janitor cloud-init (Ubuntu Zesty): status Fix Committed Fix Released
2017-05-19 09:06:56 Dimitri John Ledkov cloud-init: status Confirmed Fix Committed
2017-05-31 11:16:41 Thadeu Lima de Souza Cascardo linux (Ubuntu Xenial): status In Progress Fix Committed
2017-06-28 16:35:34 Launchpad Janitor linux (Ubuntu Xenial): status Fix Committed Fix Released
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-1000364
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-8890
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-9074
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-9075
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-9076
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-9077
2017-06-28 16:35:34 Launchpad Janitor cve linked 2017-9242
2017-09-23 02:31:03 Scott Moser cloud-init: status Fix Committed Fix Released
2023-05-10 23:47:00 James Falcon bug watch added https://github.com/canonical/cloud-init/issues/2858