solution considerations
option one has the advantage of confining the change change to os-vif.
option two is the correct approach long term as it dose not require any config
change on upgrade.
option three is a compromise as while we do not need to make any change on
upgrade we cannot hanel
the case where both datapath have been active on the system as we do not have
the authroritve infomation
from neutron to select the datapath.
option one could be implemented in a day or two.
option two would not take much longer to pull together once i figure out
exactly where in nova to extend the network object.
option three would be similar to option one in timescale.
option two would require back porting in stable newton in all three
project where as option one just requires a requirements change in
nova/neutron which would have been needed to use the windows support
anyway. option three would be the same as option one in this regard.
** Also affects: nova
Importance: Undecided
Status: New
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1632372
Title:
ovs plugin incorrectly assumes datapath is system for vif_ovs
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in os-vif:
New
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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
