[Yahoo-eng-team] [Bug 1983530] [NEW] [ovn]router_interface port probability cannot be up
Public bug reported: I have en environment, with 5 neutron-server(W version), 5 ovn(21.03.1) When adding an interface to the router, the state of the interface is sometimes down, and it will not become up after a long time. Restarting the neutron server can become up. I check logical_switch_port by "ovn-nbctl list logical_switch_port ", the status of lsp is up, and the traffic can be forwarded normally. This should only be a neutron save state problem. In the past, when creating vm, the ports have been unable to be up, and the reason has not been found. The phenomenon is the same as that of the router interface. In the process of adding a routing interface, I wrote a script to listen to logical_switch_port change, I found: before lsp becomes up=true, lsp's up=[], which is not up=[false], not matchd LogicalSwitchPortUpdateUpEvent. I don't know why ovn's notification events are sometimes different, but I think it should be repaired here in neutron ** Affects: neutron Importance: Undecided Status: New ** Description changed: I have en environment, with 5 neutron-server(W version), 5 ovn(21.03.1) - When adding an interface to the router, the state of the interface is sometimes down, + When adding an interface to the router, the state of the interface is sometimes down, and it will not become up after a long time. Restarting the neutron server can become up. - I check logical_switch_port by "ovn-nbctl list logical_switch_port ", the status + I check logical_switch_port by "ovn-nbctl list logical_switch_port ", the status of lsp is up, and the traffic can be forwarded normally. This should only be a neutron save state problem. - In the past, when creating vm, the ports have been unable to be up, and the reason has not + In the past, when creating vm, the ports have been unable to be up, and the reason has not been found. The phenomenon is the same as that of the router interface. - In the process of adding a routing interface, I wrote a script to listen to logical_switch_port - change, I found: before lsp becomes up=true, lsp's up=[], which is not up=[false], not matchd - LogicalSwitchPortUpdateUpEvent. I don't know why ovn's notification events are sometimes different, - but I think it should be repaired here in neutron + In the process of adding a routing interface, I wrote a script to listen to logical_switch_port + change, I found: before lsp becomes up=true, lsp's up=[], which is not up=[false], not + matchd LogicalSwitchPortUpdateUpEvent. I don't know why ovn's notification events are + sometimes different, but I think it should be repaired here in neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1983530 Title: [ovn]router_interface port probability cannot be up Status in neutron: New Bug description: I have en environment, with 5 neutron-server(W version), 5 ovn(21.03.1) When adding an interface to the router, the state of the interface is sometimes down, and it will not become up after a long time. Restarting the neutron server can become up. I check logical_switch_port by "ovn-nbctl list logical_switch_port ", the status of lsp is up, and the traffic can be forwarded normally. This should only be a neutron save state problem. In the past, when creating vm, the ports have been unable to be up, and the reason has not been found. The phenomenon is the same as that of the router interface. In the process of adding a routing interface, I wrote a script to listen to logical_switch_port change, I found: before lsp becomes up=true, lsp's up=[], which is not up=[false], not matchd LogicalSwitchPortUpdateUpEvent. I don't know why ovn's notification events are sometimes different, but I think it should be repaired here in neutron To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1983530/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1983516] [NEW] failed to generate config when interface was renamed
Public bug reported: 2022-08-03 18:42:31,598 - util.py[DEBUG]: Writing to /etc/netplan/50-cloud-init.yaml - wb: [644] 1359 bytes 2022-08-03 18:42:31,598 - subp.py[DEBUG]: Running command ['netplan', 'generate'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,875 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth2'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,880 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth0'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,956 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth7'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,959 - util.py[WARNING]: failed stage init-local 2022-08-03 18:42:31,959 - util.py[DEBUG]: failed stage init-local Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 740, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 410, in main_init init.apply_network_config(bring_up=bring_up_interfaces) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 937, in apply_network_config return self.distro.apply_network_config( File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 233, in apply_network_config self._write_network_state(network_state) File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 142, in _write_network_state return super()._write_network_state(network_state) File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 129, in _write_network_state renderer.render_network_state(network_state) File "/usr/lib/python3/dist-packages/cloudinit/net/netplan.py", line 260, in render_network_state self._net_setup_link(run=self._postcmds) File "/usr/lib/python3/dist-packages/cloudinit/net/netplan.py", line 282, in _net_setup_link subp.subp(cmd, capture=True) File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 335, in subp raise ProcessExecutionError( cloudinit.subp.ProcessExecutionError: Unexpected error while running command. Command: ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth7'] Exit code: 1 Reason: - Stdout: Stderr: Load module index Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link Parsed configuration file /run/systemd/network/10-netplan-eth3.link Parsed configuration file /run/systemd/network/10-netplan-eth2.link Parsed configuration file /run/systemd/network/10-netplan-eth1.link Parsed configuration file /run/systemd/network/10-netplan-eth0.link Created link configuration context. Failed to open device '/sys/class/net/eth7': No such device Unload module index Unloaded link configuration context. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1983516 Title: failed to generate config when interface was renamed Status in cloud-init: New Bug description: 2022-08-03 18:42:31,598 - util.py[DEBUG]: Writing to /etc/netplan/50-cloud-init.yaml - wb: [644] 1359 bytes 2022-08-03 18:42:31,598 - subp.py[DEBUG]: Running command ['netplan', 'generate'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,875 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth2'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,880 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth0'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,956 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth7'] with allowed return codes [0] (shell=False, capture=True) 2022-08-03 18:42:31,959 - util.py[WARNING]: failed stage init-local 2022-08-03 18:42:31,959 - util.py[DEBUG]: failed stage init-local Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 740, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 410, in main_init init.apply_network_config(bring_up=bring_up_interfaces) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 937, in apply_network_config return self.distro.apply_network_config( File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 233, in apply_network_config
[Yahoo-eng-team] [Bug 1965297] Re: l3ha don't set backup qg ports down
This bug was fixed in the package neutron - 2:16.4.2-0ubuntu3~cloud0 --- neutron (2:16.4.2-0ubuntu3~cloud0) bionic-ussuri; urgency=medium . * New update for the Ubuntu Cloud Archive. . neutron (2:16.4.2-0ubuntu3) focal; urgency=medium . * d/p/partially-revert-do-not-link-up-ha-router-gateway-in.patch: Picked from upstream to ensure that ha_confs path is created when the keepalived manager is initialised (LP: #1965297). ** Changed in: cloud-archive/ussuri Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1965297 Title: l3ha don't set backup qg ports down Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Released Status in Ubuntu Cloud Archive victoria series: Fix Released Status in Ubuntu Cloud Archive wallaby series: Fix Released Status in Ubuntu Cloud Archive xena series: Fix Released Status in Ubuntu Cloud Archive yoga series: Fix Released Status in Ubuntu Cloud Archive zed series: Fix Released Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Focal: Fix Released Status in neutron source package in Impish: Won't Fix Status in neutron source package in Jammy: Fix Released Status in neutron source package in Kinetic: Fix Released Bug description: The history to this request is as follows; bug 1916024 fixed an issue that subsequently had to be reverted due to a regression that it introduced (see bug 1927868) and the original issue can once again present itself in that keepalived is unable to send GARP on the qg port until the port is marked as UP by neutron which in loaded environments can sometimes take longer than keepalived will wait (e.g. when an l3-agent is restarted on a host that has hundreds of routers). The reason why qg- ports are marked as DOWN is because of the patch landed as part of bug 1859832 and as I understand it there is now consensus from upstream [1] to revert that patch as well and a better solution is needed to fix that particular issue. I have not found a bug open yet for the revert hence why I am opening this one. [1] https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-04-14.03.log.txt [Impact] Please see LP bug description for full details but in short, this patch is a revert of a patch that has show instability in the field for users of Neutron L3HA. [Test Plan] * Deploy Openstack with Neutron L3 HA enabled * Create a number of HA routers * Check all qrouter namespaces and ensure that the qg- port is UP in all [Regression Potential] Since the original patch was intended to address issues with MLDv2 it is possible that reverting it will re-introduce those issues and a new patch will need to be proposed to address that. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1965297/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1921388] Re: novaclient logs are logged as keystoneauth.session
** Changed in: horizon Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1921388 Title: novaclient logs are logged as keystoneauth.session Status in OpenStack Dashboard (Horizon): Fix Released Status in python-novaclient: Fix Released Bug description: This is possibly as old as Train, but I only just noticed this when I tried to debug something. All logs that should be logged as novaclient, instead get logged as keystoneauth.session — this means we can't easily configure the log level for novaclient, and makes it hard to search the logs. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1921388/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1983471] [NEW] Shelved (offloaded) instance still have port bound to host
Public bug reported: Description === When shelving an instance, the instance is removed from the compute and the image is uploaded to glance. But, after completion, the port binding on neutron side is staying. This is not a big issue in most of the case, but some operators (like OVHcloud) rely on strong consistency between nova and neutron and expect the binding to be updated to avoid orphans. As stated on IRC with sean-k-mooney, this behavior was already spotted while working on another subject (see [1]). Steps to reproduce == # Boot an instance openstack server create ... # Wait for it to be fully booted, then shelve: openstack server shelve 57b3cbf6-9aa4-4da2-90ab-20cf518ea38e # Wait for shelve to be completed (offloaded) openstack server show 57b3cbf6-9aa4-4da2-90ab-20cf518ea38e ... | OS-EXT-STS:vm_state | shelved_offloaded ... # List ports associated to the instance: openstack port list --server 57b3cbf6-9aa4-4da2-90ab-20cf518ea38e # Show the port: openstack port show f9144ff9-4261-476f-98f9-de0750f3db1a ... | binding_host_id | compute-5 | binding_vif_type| ovs ... Expected result === ... | binding_host_id | | binding_vif_type| unbound ... Environment === OpenStack victoria, but master is also affected [1] https://review.opendev.org/c/openstack/nova/+/832330/7/nova/tests/functional/libvirt/test_pci_sriov_servers.py#1286 ** Affects: nova Importance: Undecided Status: New ** Summary changed: - Shelved (offloaded) instance still have port binded to host + Shelved (offloaded) instance still have port bound to host -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1983471 Title: Shelved (offloaded) instance still have port bound to host Status in OpenStack Compute (nova): New Bug description: Description === When shelving an instance, the instance is removed from the compute and the image is uploaded to glance. But, after completion, the port binding on neutron side is staying. This is not a big issue in most of the case, but some operators (like OVHcloud) rely on strong consistency between nova and neutron and expect the binding to be updated to avoid orphans. As stated on IRC with sean-k-mooney, this behavior was already spotted while working on another subject (see [1]). Steps to reproduce == # Boot an instance openstack server create ... # Wait for it to be fully booted, then shelve: openstack server shelve 57b3cbf6-9aa4-4da2-90ab-20cf518ea38e # Wait for shelve to be completed (offloaded) openstack server show 57b3cbf6-9aa4-4da2-90ab-20cf518ea38e ... | OS-EXT-STS:vm_state | shelved_offloaded ... # List ports associated to the instance: openstack port list --server 57b3cbf6-9aa4-4da2-90ab-20cf518ea38e # Show the port: openstack port show f9144ff9-4261-476f-98f9-de0750f3db1a ... | binding_host_id | compute-5 | binding_vif_type| ovs ... Expected result === ... | binding_host_id | | binding_vif_type| unbound ... Environment === OpenStack victoria, but master is also affected [1] https://review.opendev.org/c/openstack/nova/+/832330/7/nova/tests/functional/libvirt/test_pci_sriov_servers.py#1286 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1983471/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1982373] Re: nova/neutron ignore and overwrite custom device owner fields
** Changed in: nova Status: Incomplete => Invalid ** Changed in: neutron Status: Opinion => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1982373 Title: nova/neutron ignore and overwrite custom device owner fields Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Bug description: nova/neutron ignore custom device owner fields when the device_id matches a nova server. The fact that the device_owner field is set to something other than nova is completely ignored. Sequence of command line actions: ~~~ ~~~ stack@standalone ~]$ openstack server list +--+-++-+---+---+ | ID | Name| Status | Networks| Image | Flavor| +--+-++-+---+---+ | 382c107f-a082-4e9b-8adb-2ba45323c479 | ostest-lq27s-worker-0-cz6gw | ACTIVE | ostest-lq27s-openshift=10.196.2.215 | rhcos | m1.large | | 985a609a-1fdd-4f48-b996-9311883c33a2 | ostest-lq27s-worker-0-5vcxf | ACTIVE | ostest-lq27s-openshift=10.196.2.151 | rhcos | m1.large | ~~~ ~~~ # openstack port create --network ed889e25-f8fa-4684-a9c4-54fff8de37b8 --device 382c107f-a082-4e9b-8adb-2ba45323c479 --device-owner TestOwner --fixed-ip subnet=ba4e5cdb-a0e3-47f2-9233-47d5a12c,ip-address=10.196.100.200 TestPort (...) | id | 697f4773-7fe7-4d1b-9804-8fbb003b1194 (...) # openstack port create --network ed889e25-f8fa-4684-a9c4-54fff8de37b8 --device 382c107f-a082-4e9b-8adb-2ba45323c479 --device-owner TestOwner --fixed-ip subnet=ba4e5cdb-a0e3-47f2-9233-47d5a12c,ip-address=10.196.100.201 TestPort2 (...) | id | bc22dfa9-90fa-4d70-84a8-ec3a41ea2305 (...) ~~~ Now, run this in a terminal: ~~~ while true ; do sleep 10 ; date ; openstack port show 697f4773-7fe7-4d1b-9804-8fbb003b1194 | grep device_owner; done Wed Jul 20 14:21:26 UTC 2022 | device_owner| TestOwner | Wed Jul 20 14:21:38 UTC 2022 | device_owner| TestOwner | Wed Jul 20 14:21:51 UTC 2022 | device_owner| TestOwner | Wed Jul 20 14:22:03 UTC 2022 | device_owner| TestOwner | Wed Jul 20 14:22:15 UTC 2022 | device_owner| TestOwner | Wed Jul 20 14:22:28 UTC 2022 | device_owner| TestOwner | Wed Jul 20 14:22:40 UTC 2022 | device_owner| TestOwner | (...) ~~~ In another terminal, delete and recreate the second port: ~~~ [stack@standalone ~]$ openstack port delete bc22dfa9-90fa-4d70-84a8-ec3a41ea2305 [stack@standalone ~]$ openstack port create --network ed889e25-f8fa-4684-a9c4-54fff8de37b8 --device 382c107f-a082-4e9b-8adb-2ba45323c479 --device-owner TestOwner --fixed-ip subnet=ba4e5cdb-a0e3-47f2-9233-47d5a12c,ip-address=10.196.100.201 TestPort2 (...) | id | bc22dfa9-90fa-4d70-84a8-ec3a41ea2305 (...) ~~~ Check in the terminal that's running the while loop: ~~~ Wed Jul 20 14:22:53 UTC 2022 | device_owner| TestOwner |
[Yahoo-eng-team] [Bug 1943881] Re: Server concepts in Compute API Guide
Reviewed: https://review.opendev.org/c/openstack/nova/+/851511 Committed: https://opendev.org/openstack/nova/commit/1495d802c6a6b2ce3b92d59686e1e0e23a28c21f Submitter: "Zuul (22348)" Branch:master commit 1495d802c6a6b2ce3b92d59686e1e0e23a28c21f Author: Amit Uniyal Date: Fri Jul 29 11:34:21 2022 + Updated Suspend definition in server concepts doc Closes-Bug: #1943881 Change-Id: Icb8de13f665c340cd5d863654f8ad981de21293d ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1943881 Title: Server concepts in Compute API Guide Status in OpenStack Compute (nova): Fix Released Bug description: Suspend, Resume section has confusing meaning explaining when VCPUs are available. "Suspending a server is similar to placing a device in hibernation; memory and vCPUs become available to create other servers." When VM is shutdown, it stays on a server. Its allocation is hold against an allocation of the server. Placement counts all VCPUs, for active and inactive VMs. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on OFTC --- Release: 2.1.0 on 2021-09-10 23:30:23 SHA: dc18853c316e1a7d74b99183b8f06e8d81a8f6c9 Source: https://opendev.org/openstack/nova/src/api-guide/source/server_concepts.rst URL: https://docs.openstack.org/api-guide/compute/server_concepts.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1943881/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1965297] Re: l3ha don't set backup qg ports down
This bug was fixed in the package neutron - 2:16.4.2-0ubuntu3 --- neutron (2:16.4.2-0ubuntu3) focal; urgency=medium * d/p/partially-revert-do-not-link-up-ha-router-gateway-in.patch: Picked from upstream to ensure that ha_confs path is created when the keepalived manager is initialised (LP: #1965297). -- Corey Bryant Tue, 05 Jul 2022 15:50:56 -0400 ** Changed in: neutron (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1965297 Title: l3ha don't set backup qg ports down Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Committed Status in Ubuntu Cloud Archive victoria series: Fix Released Status in Ubuntu Cloud Archive wallaby series: Fix Released Status in Ubuntu Cloud Archive xena series: Fix Released Status in Ubuntu Cloud Archive yoga series: Fix Released Status in Ubuntu Cloud Archive zed series: Fix Released Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Focal: Fix Released Status in neutron source package in Impish: Won't Fix Status in neutron source package in Jammy: Fix Released Status in neutron source package in Kinetic: Fix Released Bug description: The history to this request is as follows; bug 1916024 fixed an issue that subsequently had to be reverted due to a regression that it introduced (see bug 1927868) and the original issue can once again present itself in that keepalived is unable to send GARP on the qg port until the port is marked as UP by neutron which in loaded environments can sometimes take longer than keepalived will wait (e.g. when an l3-agent is restarted on a host that has hundreds of routers). The reason why qg- ports are marked as DOWN is because of the patch landed as part of bug 1859832 and as I understand it there is now consensus from upstream [1] to revert that patch as well and a better solution is needed to fix that particular issue. I have not found a bug open yet for the revert hence why I am opening this one. [1] https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-04-14.03.log.txt [Impact] Please see LP bug description for full details but in short, this patch is a revert of a patch that has show instability in the field for users of Neutron L3HA. [Test Plan] * Deploy Openstack with Neutron L3 HA enabled * Create a number of HA routers * Check all qrouter namespaces and ensure that the qg- port is UP in all [Regression Potential] Since the original patch was intended to address issues with MLDv2 it is possible that reverting it will re-introduce those issues and a new patch will need to be proposed to address that. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1965297/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
