Bug 2159677 - HM status not conditional on the status of the existing members
Summary: HM status not conditional on the status of the existing members
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-ovn-octavia-provider
Version: 17.0 (Wallaby)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ga
: 17.1
Assignee: Fernando Royo
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-10 11:30 UTC by Fernando Royo
Modified: 2023-09-24 17:31 UTC (History)
1 user (show)

Fixed In Version: python-ovn-octavia-provider-1.0.3-1.20221227155353.0d529f7.el8ost
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-16 01:13:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 2000071 0 None None None 2023-01-10 11:30:46 UTC
OpenStack gerrit 868411 0 None MERGED Uncouple HM status of member statuses 2023-01-10 11:35:33 UTC
Red Hat Issue Tracker OSP-21286 0 None None None 2023-01-10 11:39:34 UTC
Red Hat Product Errata RHEA-2023:4577 0 None None None 2023-08-16 01:13:31 UTC

Description Fernando Royo 2023-01-10 11:30:47 UTC
Description of problem:
When a new HM is created for a LB (ovn-provider), it is checking the member status, if any of the member (ports related) is not found the HM is created with ERROR provisioning status. It doesn't make sense if we take into account that the HM is an independent entity and should not see its status conditioned by the status of the members it will monitor.

Steps to Reproduce:
1. Creation of a pool (pool1)
2. Creation of a member (member1) associated to the previous pool (pool1), which starts in ACTIVE
3. Creation of a member (member2) associated to the previous pool (pool1), which starts in ERROR status for example because we have invented the member address.
4. Creation of a HM associated to the pool (pool1)

Actual results:
as output the HM will be in ERROR.

Expected results:
If we do the same steps in a bulk request the output will be HM as ACTIVE and the members as expected (member1 ACTIVE, member2 ERROR)

Comment 6 Lukas Svaty 2023-06-16 08:13:29 UTC
Bulk moving target milestone to GA after the release of Beta on 14th June '23.

Comment 13 errata-xmlrpc 2023-08-16 01:13:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2023:4577


Note You need to log in before you can comment on or make changes to this bug.