yahoo-eng-team team mailing list archive

[Fernando Royo <1965772@xxxxxxxxxxxxxxxxxx>]

** Changed in: neutron
       Status: In Progress => Fix Released

** 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/1965772

Title:
  ovn-octavia-provider does not report status correctly to octavia

Status in neutron:
  Fix Released

Bug description:
  Hi all,

  The OVN Octavia provider does not report status correctly to Octavia
  due to a few bugs in the health monitoring implementation:

  1) https://opendev.org/openstack/ovn-octavia-provider/src/commit/d6adbcef86e32bc7befbd5890a2bc79256b7a8e2/ovn_octavia_provider/helper.py#L2374 :
  In _get_lb_on_hm_event, the request to the OVN NB API (db_find_rows) is incorrect:
          lbs = self.ovn_nbdb_api.db_find_rows(
              'Load_Balancer', (('ip_port_mappings', '=', mappings),
                                ('protocol', '=', row.protocol))).execute()

  Should be :
          lbs = self.ovn_nbdb_api.db_find_rows(
              'Load_Balancer', ('ip_port_mappings', '=', mappings),
                                ('protocol', '=', row.protocol[0])).execute()

  Note the removed extra parenthesis and the protocol string which is
  found in the first element of the protocol[] list.

  2) https://opendev.org/openstack/ovn-octavia-
  provider/src/commit/d6adbcef86e32bc7befbd5890a2bc79256b7a8e2/ovn_octavia_provider/helper.py#L2426
  :

  There is a confusion with the Pool object returned by (pool =
  self._octavia_driver_lib.get_pool(pool_id)) : this object does not
  contain any operating_status attribute and it seems given the current
  state of the octavia-lib that it possible to set and update the status
  for a listener/pool/member but not possible to retrieve the current
  status.

  See https://opendev.org/openstack/octavia-
  lib/src/branch/master/octavia_lib/api/drivers/data_models.py for the
  current Pool data model.

  As a result, the computation done by _get_new_operating_statuses
  cannot use the current operating status to set a new operating status.
  It is still possible to set an operating status for the members by
  setting them to "OFFLINE" separately when a HM update event is fired.

  3) The Load_Balancer_Health_Check NB entry creates the Service_Monitor
  SB entries, but there isn't any way to link the Service_Monitor
  entries created with the original NB entry. The result is that health
  monitor events received from the SB and processed by the octavia
  driver agent cannot be accurately matched with the correct octavia
  health monitor entry. If we have for example two load balancer entries
  using the same pool members and the same ports, only the first LB
  returned with db_find_rows would be updated (given the #2 bug is
  fixed). The case for having 2 load balancers with the same members is
  perfectly valid when using separate load balancers for public traffic
  (using a VIP from a public pool) and another one for internal/admin
  traffic (using a VIP from another pool, and with a source range
  whitelist). The code selecting only the first LB in that case is the
  same as bug #1.

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