yahoo-eng-team team mailing list archive

[OpenStack Infra <2000071@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/868092
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4
Submitter: "Zuul (22348)"
Branch:    master

commit 548d65d1a50612c6b24f85e6ffbdd1cd32bae8e4
Author: Fernando Royo <froyo@xxxxxxxxxx>
Date:   Mon Dec 19 15:36:41 2022 +0100

    Uncouple HM status of member statuses
    
    When a new HM is created, the provisioning status is conditioned
    by the status of the existing members on the pool. When any of
    the members are in ERROR status (e.g. when a member is configure
    with non existing address) the created HM is in ERROR status.
    
    It makes more sense to warn about the member problem but let the
    HM continue with its normal flow of operation over the possible
    remaining members that exist for the pool on which it is created.
    This patch removes the break after finding a problematic member
    (port not found) and just log a warning about the issue, but
    continue with the rest of the members.
    
    Closes-Bug: #2000071
    Change-Id: I5be9130eb63c03d273fc8dfcc93094204a3ed361


** Changed in: neutron
       Status: In Progress => 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/2000071

Title:
  [ovn-octavia-provider] Do not make the status of a newly HM
  conditional on the status of existing members

Status in neutron:
  Fix Released

Bug description:
  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.

  In fact, this behaviour only occurs if we follow these steps secuen:

  - Creation of a pool (pool1)
  - Creation of a member (member1) associated to the previous pool (pool1), which starts in ACTIVE
  - 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.
  - Creation of a HM associated to the pool (pool1)

  as output the HM will be in ERROR.

  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2000071/+subscriptions