yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #90805
[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