yahoo-eng-team team mailing list archive

[Bernard Cafarelli <1865889@xxxxxxxxxxxxxxxxxx>]

Doc is also merged, updating status on this one

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

Title:
  [RFE] Routed provider networks support in OVN

Status in neutron:
  Fix Released

Bug description:
  The routed provider networks feature doesn't work properly with OVN
  backend. While API doesn't return any errors, all the ports are
  allocated to the same OVN Logical Switch and besides providing no
  Layer2 isolation whatsoever, it won't work when multiple segments
  using different physnets are added to such network.

  The reason for the latter is that, currently, in core OVN, only one
  localnet port is supported per Logical Switch so only one physical net
  can be associated to it. I can think of two different approaches:

  1) Change the OVN mech driver to logically separate Neutron segments:

  a) Create an OVN Logical Switch *per Neutron segment*. This has some
  challenges from a consistency point of view as right now there's a 1:1
  mapping between a Neutron Network and an OVN Logical Switch. Revision
  numbers, maintenance task, OVN DB Sync script, etcetera.

  b) Each of those Logical Switches will have a localnet port associated
  to the physnet of the Neutron segment.

  c) The port still belongs to the parent network so all the CRUD operations over a port will require to figure out which underlying OVN LS applies (depending on which segment the port lives in).
  The same goes for other objects (e.g. OVN Load Balancers, gw ports -if attaching a multisegment network to a Neutron router as a gateway is a valid use case at all-).

  e) Deferred allocation. A port can be created in a multisegment
  Neutron network but the IP allocation is deferred to the time where a
  compute node is assigned to an instance. In this case the OVN mech
  driver might need to move around the Logical Switch Port from the
  Logical Switch of the parent to that of the segment where it falls
  (can be prone to race conditions :?).

  
  2) Core OVN changes:

  The current limitation is that right now only one localnet port is
  allowed per Logical Switch so we can't map different physnets to it.
  If we add support for multiple localnet ports in core OVN, we can have
  all the segments living in the same OVN Logical Switch.

  My idea here would be:

  a) Per each Neutron segment, we create a localnet port in the single
  OVN Logical Switch with its physnet and vlan id (if any). Eg.

  name                : provnet-f7038db6-7376-4b83-b57b-3f456bea2b80
  options             : {network_name=segment1}
  parent_name         : []
  port_security       : []
  tag                 : 2016
  tag_request         : []
  type                : localnet

  
  name                : provnet-84487aa7-5ac7-4f07-877e-1840d325e3de
  options             : {network_name=segment2}
  parent_name         : []
  port_security       : []
  tag                 : 2017
  tag_request         : []
  type                : localnet

  And both ports would belong to the LS corresponding to the
  multisegment Neutron network.

  b) In this case, when ovn-controller sees that a port in that network
  has been bound to it, all it needs to create is the patch port to the
  provider bridge that the bridge mappings configuration dictates.

  E.g

  compute1:    bridge-mappings = segment1:br-provider1
  compute2:    bridge-mappings = segment2:br-provider2

  When a port in the multisegment network gets bound to compute1, ovn-
  controller will create a patch-port between br-int and br-provider1.
  The restriction here is that on a given hypervisor, only ports
  belonging to the same segment will be present. ie. we can't mix VMs on
  different segments on the same hypervisor.

  
  c) Minor changes are required in the Neutron side (just creating the localnet port upon segment creation).

  
  We need to discuss if the restriction mentioned earlier makes sense. If not, perhaps we need to drop this approach completely or look for core OVN alternatives.

  
  I'd lean on approach number 2 as it seems the less invasive in terms of code changes but there's the catch described that may make it a no-go or explore another ways to eliminate that restriction somehow in core OVN.

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