ovs plugin incorrectly assumes datapath is system for vif_ovs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
Unassigned | ||
neutron |
Fix Released
|
Undecided
|
Rodolfo Alonso | ||
os-vif |
Fix Released
|
Medium
|
Rodolfo Alonso |
Bug Description
the ovs plugin currently uses hardcoded datapath types when plugin interfaces.
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:/
kernel datapath is not available.
this bug was introduced as part of https:/
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:/
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_
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:/
tags: | added: ovs |
Changed in neutron: | |
status: | New → Invalid |
Changed in os-vif: | |
status: | New → Confirmed |
Changed in nova: | |
status: | New → Incomplete |
Changed in os-vif: | |
assignee: | nobody → Rodolfo Alonso (rodolfo-alonso-hernandez) |
Changed in nova: | |
status: | Incomplete → In Progress |
Changed in neutron: | |
assignee: | Rodolfo Alonso (rodolfo-alonso-hernandez) → Kevin Benton (kevinbenton) |
Changed in neutron: | |
assignee: | Kevin Benton (kevinbenton) → Rodolfo Alonso (rodolfo-alonso-hernandez) |
tags: | added: neutron-proactive-backport-potential |
Changed in nova: | |
status: | In Progress → Fix Released |
Changed in neutron: | |
status: | In Progress → Fix Released |
possible solutions.
1.) introduce a config variable to set the datapath type for the VIF_OVS type. this would mirror the ovs agent datapath type variable in neutron /github. com/openstack/ neutron/ blob/f0ca030595 cb7484be338c567 8738b2e536b2369 /neutron/ plugins/ ml2/drivers/ openvswitch/ agent/common/ config. py#L75- L80
https:/
this would require no changes to nova or neutron but would adress the regression in fuctionality but require operators to set the config value if they happened to use the netdev datapath without dpdk e.g. not use vhost-user interfaces.
2.) modify the neutron ml2 dirver here to pass the datapath type to nova via the vif_details. /github. com/openstack/ neutron/ blob/f0ca030595 cb7484be338c567 8738b2e536b2369 /neutron/ plugins/ ml2/drivers/ openvswitch/ mech_driver/ mech_openvswitc h.py#L108- L128 /github. com/openstack/ os-vif/ blob/master/ os_vif/ objects/ network. py to store the datapath and modify the os-vif ovs plugin to read it just as we do with the bridge name here /github. com/openstack/ os-vif/ blob/9fb7fe5129 02a37432e38d884 b8be59ce91582db /vif_plug_ ovs/ovs. py#L100- L101
https:/
then modify the os-vif network object
https:/
https:/
also need to modify nova to retrieve the datapath type form the vif_details and populated the value in the os-vif network object.
3.) since neutron requires all bridges to be of the same datapath type
so that patch ports will work we can list the active datapath types using ovs-appctl.
if only one datapath type is active then that is the type that should be used for the bridge.
if both datapaths are active we could raise an exception and refuse to plug the interface or make a best effort guess.