Back to bug 2135270
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Luis Tomas Bolivar | 2022-10-17 07:25:48 UTC | Assignee | rhos-maint | ltomasbo |
| Keywords | Triaged | |||
| Target Release | --- | 17.0 | ||
| Target Milestone | --- | z1 | ||
| Priority | unspecified | high | ||
| RHEL Program Management | 2022-10-17 07:25:57 UTC | Target Release | 17.0 | --- |
| Luis Tomas Bolivar | 2022-10-17 07:27:03 UTC | Target Release | --- | 17.0 |
| Status | NEW | ASSIGNED | ||
| RHEL Program Management | 2022-10-17 07:27:12 UTC | Target Release | 17.0 --- | --- 17.0 |
| Luis Tomas Bolivar | 2022-10-17 07:28:23 UTC | Blocks | 2135271 | |
| Red Hat One Jira (issues.redhat.com) | 2022-10-17 07:41:30 UTC | Link ID | Red Hat Issue Tracker OSP-19464 | |
| Luis Tomas Bolivar | 2022-10-19 05:53:33 UTC | Blocks | 2136017 | |
| Luis Tomas Bolivar | 2022-10-28 13:11:25 UTC | Status | ASSIGNED | ON_DEV |
| Link ID | OpenStack gerrit 862585 OpenStack gerrit 862891 | |||
| Luis Tomas Bolivar | 2022-11-02 13:27:25 UTC | Status | ON_DEV | POST |
| Luis Tomas Bolivar | 2022-11-03 17:46:11 UTC | Status | POST | MODIFIED |
| Fixed In Version | python-ovn-octavia-provider-1.0.1-0.20221103150644.bbf881f.el9osttrunk | |||
| OSP Team | 2022-11-30 07:03:39 UTC | Fixed In Version | python-ovn-octavia-provider-1.0.1-0.20221103150644.bbf881f.el9osttrunk | python-ovn-octavia-provider-1.0.1-0.20221122190308.bbf881f.el9ost |
| errata-xmlrpc | 2022-12-06 00:50:20 UTC | Status | MODIFIED | ON_QA |
| Omer Schwartz | 2022-12-16 15:50:28 UTC | Flags | needinfo?(ltomasbo) | |
| CC | oschwart | |||
| Luis Tomas Bolivar | 2022-12-16 16:24:21 UTC | Flags | needinfo?(ltomasbo) | |
| Eran Kuris | 2022-12-19 07:07:50 UTC | QA Contact | ekuris | bbonguar |
| Omer Schwartz | 2022-12-20 09:29:46 UTC | Status | ON_QA | VERIFIED |
| Andy Stillman | 2023-01-11 18:40:41 UTC | Flags | needinfo?(ltomasbo) | |
| Luis Tomas Bolivar | 2023-01-12 06:57:56 UTC | Doc Type | If docs needed, set a value | Bug Fix |
| Doc Text | Cause: If an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 + IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath Consequence: When readding the LS to the LR (i.e. the network/subnets to the router) the ovn-lb won't be properly associated to the LR/LS at OVN level and there will be no connectivity Fix: This patch checks the IP version so that router ports that belongs to other subnets are not considered and the ovn-lb is not therefore removed from the LS Result: ovn-lb has proper connectivity upon one of the subnet removal from the router |
|||
| Luis Tomas Bolivar | 2023-01-16 14:12:28 UTC | Flags | needinfo?(ltomasbo) | |
| Erin Peterson | 2023-01-19 18:27:07 UTC | Doc Text | Cause: If an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 + IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath Consequence: When readding the LS to the LR (i.e. the network/subnets to the router) the ovn-lb won't be properly associated to the LR/LS at OVN level and there will be no connectivity Fix: This patch checks the IP version so that router ports that belongs to other subnets are not considered and the ovn-lb is not therefore removed from the LS Result: ovn-lb has proper connectivity upon one of the subnet removal from the router | Before this update, if an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 and IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath. When re-adding the LS to the LR (the network and subnets to the router) the ovn-lb will not be properly associated to the LR/LS at OVN level and there will be no connectivity With this update the IP version is checked so that router ports that belong to other subnets are not considereed and the ovn-lb is not removed from the LS. This results in the ovn-lb having proper connectivity when a subnet is removed from the router. This resolves the issue. |
| CC | erpeters | |||
| Erin Peterson | 2023-01-23 15:32:12 UTC | Doc Text | Before this update, if an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 and IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath. When re-adding the LS to the LR (the network and subnets to the router) the ovn-lb will not be properly associated to the LR/LS at OVN level and there will be no connectivity With this update the IP version is checked so that router ports that belong to other subnets are not considereed and the ovn-lb is not removed from the LS. This results in the ovn-lb having proper connectivity when a subnet is removed from the router. This resolves the issue. | Before this update, if an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 and IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath. When re-adding the LS to the LR (the network and subnets to the router) the ovn-lb will not be properly associated to the LR/LS at OVN level and there will be no connectivity + With this update the IP version is checked so that router ports that belong to other subnets are not considereed and the ovn-lb is not removed from the LS. This results in the ovn-lb having proper connectivity when a subnet is removed from the router. This resolves the issue. |
| Greg Rakauskas | 2023-01-24 17:44:23 UTC | Doc Text | Before this update, if an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 and IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath. When re-adding the LS to the LR (the network and subnets to the router) the ovn-lb will not be properly associated to the LR/LS at OVN level and there will be no connectivity + With this update the IP version is checked so that router ports that belong to other subnets are not considereed and the ovn-lb is not removed from the LS. This results in the ovn-lb having proper connectivity when a subnet is removed from the router. This resolves the issue. | Before this update, when you re-added a logical switch (LS) to a logical router (LR) the ML2/OVN load balancer would lose connectivity. This problem would occur to load balancers on OpenStack Networking service (neutron) networks that contained IPv4 and IPv6 subnets and were connected to an LR. When a subnet was first removed from the network, the load balancer would improperly lose its association to the datapath, because it was incorrectly assumed that all router ports that belong to all subnets were being removed and the load balancer was removed from the OVN southbound database. + In Red Hat OpenStack Platform 17.0.1, the IP version is checked so that router ports that belong to other subnets are not considered, and the ML2/OVN load balancer is not removed from the LS. This results in the load balancer having proper connectivity when a subnet is removed from the router and resolves the issue. |
| CC | gregraka | |||
| errata-xmlrpc | 2023-01-25 00:06:45 UTC | Status | VERIFIED | RELEASE_PENDING |
| Luis Tomas Bolivar | 2023-01-25 05:34:08 UTC | Doc Text | Before this update, when you re-added a logical switch (LS) to a logical router (LR) the ML2/OVN load balancer would lose connectivity. This problem would occur to load balancers on OpenStack Networking service (neutron) networks that contained IPv4 and IPv6 subnets and were connected to an LR. When a subnet was first removed from the network, the load balancer would improperly lose its association to the datapath, because it was incorrectly assumed that all router ports that belong to all subnets were being removed and the load balancer was removed from the OVN southbound database. + In Red Hat OpenStack Platform 17.0.1, the IP version is checked so that router ports that belong to other subnets are not considered, and the ML2/OVN load balancer is not removed from the LS. This results in the load balancer having proper connectivity when a subnet is removed from the router and resolves the issue. | Before this update, when you re-added a logical switch (LS) to a logical router (LR) the OVN load balancer would lose connectivity. This problem would occur to OVN load balancers on OpenStack Networking service (neutron) networks that contained IPv4 and IPv6 subnets and were connected to an LR. When a subnet was first removed from the network, the load balancer would improperly lose its association to the datapath, because it was incorrectly assumed that all router ports that belong to all subnets were being removed and the load balancer was removed from the OVN southbound database. In Red Hat OpenStack Platform 17.0.1, the IP version is checked so that router ports that belong to other subnets are not considered, and the OVN load balancer is not removed from the LS. This results in the load balancer having proper connectivity when a subnet is removed from the router and resolves the issue. |
| errata-xmlrpc | 2023-01-25 12:29:56 UTC | Resolution | --- | ERRATA |
| Status | RELEASE_PENDING | CLOSED | ||
| Last Closed | 2023-01-25 12:29:56 UTC | |||
| errata-xmlrpc | 2023-01-25 12:30:28 UTC | Link ID | Red Hat Product Errata RHBA-2023:0271 | |
| Greg Rakauskas | 2023-01-25 14:24:28 UTC | Doc Text | Before this update, when you re-added a logical switch (LS) to a logical router (LR) the OVN load balancer would lose connectivity. This problem would occur to OVN load balancers on OpenStack Networking service (neutron) networks that contained IPv4 and IPv6 subnets and were connected to an LR. When a subnet was first removed from the network, the load balancer would improperly lose its association to the datapath, because it was incorrectly assumed that all router ports that belong to all subnets were being removed and the load balancer was removed from the OVN southbound database. In Red Hat OpenStack Platform 17.0.1, the IP version is checked so that router ports that belong to other subnets are not considered, and the OVN load balancer is not removed from the LS. This results in the load balancer having proper connectivity when a subnet is removed from the router and resolves the issue. | Before this update, when you re-added a logical switch (LS) to a logical router (LR) the OVN load balancer would lose connectivity. This problem would occur to OVN load balancers on OpenStack Networking service (neutron) networks that contained IPv4 and IPv6 subnets and were connected to an LR. When a subnet was first removed from the network, the load balancer would improperly lose its association to the datapath, because it was incorrectly assumed that all router ports that belong to all subnets were being removed and the load balancer was removed from the OVN southbound database. + In Red Hat OpenStack Platform 17.0.1, the IP version is checked so that router ports that belong to other subnets are not considered, and the OVN load balancer is not removed from the LS. This results in the load balancer having proper connectivity when a subnet is removed from the router and resolves the issue. |
Back to bug 2135270