← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2000071] [NEW] [ovn-octavia-provider] Do not make the status of a newly HM conditional on the status of existing members

 

Public bug reported:

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)

** Affects: neutron
     Importance: Undecided
     Assignee: Fernando Royo (froyoredhat)
         Status: New


** Tags: ovn-octavia-provider

** Changed in: neutron
     Assignee: (unassigned) => Fernando Royo (froyoredhat)

-- 
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:
  New

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



Follow ups