yahoo-eng-team team mailing list archive

[OpenStack Infra <1632372@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/474914
Committed: https://git.openstack.org/cgit/openstack/os-vif/commit/?id=3b606b06e138787c1b1ffd1dd0fb43e971ee7e29
Submitter: Jenkins
Branch:    master

commit 3b606b06e138787c1b1ffd1dd0fb43e971ee7e29
Author: Rodolfo Alonso Hernandez <rodolfo.alonso.hernandez@xxxxxxxxx>
Date:   Thu Jun 15 16:00:33 2017 +0100

    Read datapath_type from VIF object
    
    When vif_plug_ovs.linux_net.ensure_ovs_bridge function is called, the
    datapath_type of the bridge should be read from the VIF object, instead
    of statically coercing a value.
    
    Closes-Bug: #1632372
    
    Change-Id: Ia813c39e2917ff373f8e1f85c75fc22d109c94d3


** Changed in: os-vif
       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/1632372

Title:
  ovs plugin incorrectly assumes datapath is system for vif_ovs

Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in os-vif:
  Fix Released

Bug description:
  the ovs plugin currently uses hardcoded datapath types when plugin
  interfaces.

  https://github.com/openstack/os-
  vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L100-L101

  https://github.com/openstack/os-
  vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L127-L128

  https://github.com/openstack/os-
  vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L135-L136

  https://github.com/openstack/os-
  vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L149-L150

  while this works in the general case it dose not work if ovs is configured to use the netdev datapath without dpdk. This can be done by setting the datapath type in the neutron agent config 
  https://github.com/openstack/neutron/blob/f0ca030595cb7484be338c5678738b2e536b2369/neutron/plugins/ml2/drivers/openvswitch/agent/common/config.py#L75-L80 and is required to support ovs on bsd where the
  kernel datapath is not available.

  this bug was introduced as part of https://github.com/openstack/os-
  vif/commit/3d62d8e23c99bdf4fcfaab15c6dd2e341d5c9bfa

  the observed behavior is as follows.

  the ovs neutron agent is configured to managed ovs with datapath set to netdev.
  the user boots a vm on this host.
  os-vif receives a request to plug a openvswich interface. 

  as part of the plug_bridge method
  ensure_ovs_bridge is called with br-int as the bridge name and system as the datapath.
  https://github.com/openstack/os-vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L127-L128

  the bridge name could be different if we are plunging an interface for
  the vlan aware vms spec.

  the call to ensure_ovs_bridge result in the following command being executed.
  'ovs-vsctl --may-exist add-br br-int -- set Bridge br-int datapath_type=system'

  this has the effect of changing the datapath type on the bridge from
  netdev to system.

  if the kernel module is loaded the plugging of the vif will succeed
  but network connectivity will be broken between hosts. This is because
  the br-int  or trunk bridge will not be able to comunicate via patch
  ports to the other bridges as the datapaths do not match.

  if the kernel module is not loaded the system datapath will not be
  avaiable to activate. in this the neutron ovs neutron agent will lose
  the ablity to program ovs as all ovs-ofctl commands will fail or the
  native driver equivalent. in this case the vm will fail to spawn and
  any existing vms will lose external connectivy.

  as a result on a system without the kernel module such as bsd or
  windows/linux if the module is just not loaded the use of the netev
  datapath is not possible with vif_ovs port type. This is a regression
  from mitaka functionality which was introduced in os-vif 1.2.0 by
  https://github.com/openstack/os-
  vif/commit/3d62d8e23c99bdf4fcfaab15c6dd2e341d5c9bfa.

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