Back to bug 2169349
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat One Jira (issues.redhat.com) | 2023-02-13 11:40:58 UTC | Link ID | Red Hat Issue Tracker OSP-22285 | |
| Fernando Royo | 2023-02-13 11:43:35 UTC | Assignee | rhos-maint | froyo |
| Keywords | Triaged | |||
| Status | NEW | ON_DEV | ||
| Fernando Royo | 2023-02-13 11:44:33 UTC | Link ID | OpenStack gerrit 873426 | |
| Fernando Royo | 2023-02-13 13:13:59 UTC | Priority | unspecified | high |
| Gregory Thiemonge | 2023-02-14 09:23:47 UTC | Target Release | --- | 17.0 |
| Target Milestone | --- | async | ||
| Maysa Macedo | 2023-02-22 13:12:26 UTC | CC | mdemaced | |
| Fernando Royo | 2023-02-23 11:55:54 UTC | Status | ON_DEV | POST |
| Mike Burns | 2023-03-14 11:33:18 UTC | CC | mburns | |
| Fernando Royo | 2023-03-16 10:59:47 UTC | Target Release | 17.0 | 17.1 |
| Target Milestone | async | ga | ||
| Fernando Royo | 2023-03-16 11:03:29 UTC | Status | POST | MODIFIED |
| Fixed In Version | python-ovn-octavia-provider-3.0.1-0.20230223165447.fac557f.el9osttrunk | |||
| Fernando Royo | 2023-03-16 11:08:53 UTC | Fixed In Version | python-ovn-octavia-provider-3.0.1-0.20230223165447.fac557f.el9osttrunk | python-ovn-octavia-provider-1.0.3-1.20230223161047.82a4691.el9ost |
| errata-xmlrpc | 2023-03-21 13:32:30 UTC | Status | MODIFIED | ON_QA |
| Eran Kuris | 2023-03-23 13:14:54 UTC | QA Contact | ekuris | bbonguar |
| Tom Weininger | 2023-03-28 12:10:37 UTC | CC | tweining | |
| Omer Schwartz | 2023-05-05 09:00:17 UTC | Status | ON_QA | VERIFIED |
| QA Contact | bbonguar | oschwart | ||
| CC | oschwart | |||
| Andy Stillman | 2023-05-26 12:37:59 UTC | Flags | needinfo?(froyo) | |
| Fernando Royo | 2023-05-26 13:40:42 UTC | Flags | needinfo?(froyo) | |
| Doc Text | Cause: Health monitor checks are using ovn-metadata-port Consequence: Instances are unable to get metadata, because LB health monitor is replying the arp request for OVN metadata agent's IP causing the request going to metadata agent actually being sent to another MAC address. In a nutshell, instances are loosing communication with the ovn-metadata-port. Fix: After this fix, ovn-controller now conducts backend checks using a dedicated port exclusively designed for this purpose. It replaces the previous utilization of the ovn-metadata-port. Consequently, when establishing a Health Monitor for a Load Balancer (LB) pool, it is important to ensure the existence of an available IP within the VIP LB's subnet. This port is distinct for each subnet and can be reused by various Health Monitors within the same subnet. Result: Health monitor checks not affecting to the instances metadata port communications | |||
| Doc Type | If docs needed, set a value | Bug Fix | ||
| Jenny-Anne Lynch | 2023-06-07 12:31:21 UTC | Flags | needinfo?(froyo) | |
| CC | jelynch | |||
| Doc Text | Cause: Health monitor checks are using ovn-metadata-port Consequence: Instances are unable to get metadata, because LB health monitor is replying the arp request for OVN metadata agent's IP causing the request going to metadata agent actually being sent to another MAC address. In a nutshell, instances are loosing communication with the ovn-metadata-port. Fix: After this fix, ovn-controller now conducts backend checks using a dedicated port exclusively designed for this purpose. It replaces the previous utilization of the ovn-metadata-port. Consequently, when establishing a Health Monitor for a Load Balancer (LB) pool, it is important to ensure the existence of an available IP within the VIP LB's subnet. This port is distinct for each subnet and can be reused by various Health Monitors within the same subnet. Result: Health monitor checks not affecting to the instances metadata port communications | Before this update, instances were losing communication with the ovn-metadata-port because load balancer health monitor checks were using the ovn-metadata-port to reply to ARP requests for the IP addresses of OVN metadata agents. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. | ||
| Fernando Royo | 2023-06-07 13:25:05 UTC | Doc Text | Before this update, instances were losing communication with the ovn-metadata-port because load balancer health monitor checks were using the ovn-metadata-port to reply to ARP requests for the IP addresses of OVN metadata agents. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. | Before this update, instances were losing communication with the ovn-metadata-port because load balancer health monitor is replying the ARP requests for OVN metadata agent's IP causing the request going to metadata agent actually being sent to another MAC address. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. |
| Flags | needinfo?(froyo) | |||
| Jenny-Anne Lynch | 2023-06-07 14:33:13 UTC | Doc Text | Before this update, instances were losing communication with the ovn-metadata-port because load balancer health monitor is replying the ARP requests for OVN metadata agent's IP causing the request going to metadata agent actually being sent to another MAC address. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. | Before this update, instances were losing communication with the ovn-metadata-port because the load balancer health monitor was replying to the ARP requests for the OVN metadata agent's IP, causing the request going to the metadata agent to be sent to another MAC address. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. |
| Jenny-Anne Lynch | 2023-07-19 14:26:14 UTC | CC | jelynch | |
| James Smith | 2023-08-13 20:36:45 UTC | Doc Text | Before this update, instances were losing communication with the ovn-metadata-port because the load balancer health monitor was replying to the ARP requests for the OVN metadata agent's IP, causing the request going to the metadata agent to be sent to another MAC address. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. | Before this update, instances lost communication with the ovn-metadata-port because the load balancer health monitor replied to the ARP requests for the OVN metadata agent's IP, causing the request going to the metadata agent to be sent to another MAC address. With this update, the ovn-controller conducts back-end checks by using a dedicated port instead of the ovn-metadata-port. When establishing a health monitor for a load balancer pool, ensure that there is an available IP in the VIP load balancer's subnet. This port is distinct for each subnet, and various health monitors in the same subnet can reuse the port. Health monitor checks no longer impact ovn-metadata-port communications for instances. |
| CC | jamsmith | |||
| errata-xmlrpc | 2023-08-16 00:04:44 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2023-08-16 01:13:48 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2023-08-16 01:13:48 UTC | |||
| errata-xmlrpc | 2023-08-16 01:14:11 UTC | Link ID | Red Hat Product Errata RHEA-2023:4577 |
Back to bug 2169349