← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1949967] Re: [OVN] OVN mech driver does not map new segments

 

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/816856
Committed: https://opendev.org/openstack/neutron/commit/c8427c82dae38154df70400f7d2fe69f0d6c3354
Submitter: "Zuul (22348)"
Branch:    master

commit c8427c82dae38154df70400f7d2fe69f0d6c3354
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date:   Fri Nov 5 14:56:15 2021 +0000

    [OVN] Check new added segments in OVN mech driver
    
    Check new segments added to OVN mechanism driver. This mechanism
    driver does not inherit from ``SimpleAgentMechanismDriverBase``
    because OVN has no agents (NOTE 1). However OVN mechanism driver
    requires an OVN controller service in each deployed chassis. This
    is how OVN driver knows the hosts using this backend.
    
    The segments, attached to an external network (connected to a
    physical network), can be mapped to a host if ther is a chassis (OVN
    controller agent) in this host.
    
    NOTE 1: OVN provides agent API compatibility, presenting the
    controller and the metadata services as agents. But OVN mechanism
    driver has no control or provides any information (via RPC) to
    those services.
    
    Closes-Bug: #1949967
    Change-Id: I570b2251da8a4a25d155ba838346b24afafd727f


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

Title:
  [OVN] OVN mech driver does not map new segments

Status in neutron:
  Fix Released

Bug description:
  Related LP bug: https://bugs.launchpad.net/neutron/+bug/1865889
  Related bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2013820

  This bug is related to OVN backend. "segments" service plugin must be
  enabled.

  When a new segment is created (for example when a network is created),
  if this segment is associated to a physnet (flat and vlan type
  networks) and there is an L2 agent is running on a host with this
  physnet, a new "SegmentHostMappings" register is created. This segment
  links this new segment with the host. That means we link a segment
  with a host when (1) a physnet is mapped in a host and (2) a L2 agent
  is deployed in this host (and informs about it).

  In OVN the physnet <-> host mapping is done using the OVS DB [1]:
  $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-provider

  When an OVS DB is updated, the corresponding OVN SB chassis register
  is updated. This event is captured in Neutron. Neutron retrieves the
  current segments associated to the configured physnets (in the example
  "provider") and filters by network type (flat and vlan only). If any
  of those segments has no "SegmentHostMappings", a new register is
  created.

  However when a new segment is created, OVN mech driver does not
  correctly check if this segment is located in an agent [2]. Because
  OVN mech driver has no "agent_type", this method never maps the new
  created segment with a host.

  As reported in the bugzilla #2013820, OVN can be deployed with DHCP
  agents (for baremetal servers with Ironic). When a new network (and
  the corresponding segment) is created and a new subnet is added to
  this network, the DHCP agent receives this update. But Neutron server
  [3] reports this subnet as "non_local_subnets" because there is no
  mapping between this segment and the DHCP host. Because of this, the
  DHCP deletes/do not create the DHCP namespace and the DHCP port.

  
  [1]https://docs.openstack.org/networking-ovn/2.0.1/refarch/provider-networks.html
  [2]https://github.com/openstack/neutron/blob/f97baa0b16687453735e46e7a0f73fe03d7d4db7/neutron/plugins/ml2/plugin.py#L2351-L2357
  [3]https://github.com/openstack/neutron/blob/9241c76b04e6745cc648ee42037cfe6ddad3600a/neutron/api/rpc/handlers/dhcp_rpc.py#L210-L257

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



References