Open Stack

On Fri, 2019-11-22 at 11:17 -0500, Mohammed Naser wrote:
> On Fri, Nov 22, 2019 at 10:22 AM Brian Haley <haleyb.dev at gmail.com> wrote:
> > 
> > Hi,
> > 
> > For some time we have been discussing in the Neutron community the
> > possibility of including the networking-ovn driver [1] as one of the
> > in-tree Neutron drivers.  There is already a spec [2] describing in
> > detail why we want to do this and why we think it is good idea.  We also
> > discussed this during the PTG in Shanghai within our team [3], and had a
> > discussion at the ops-meetup as well [4].
> > 
> > The OVN backend is free of many well-known issues which are impacting
> > the existing ML2/OVS reference implementation today with the OVS agent.
> > For example, OVN provides:
> > 
> > * Control plane performance optimizations by not using rabbitmq;
> > * DVR (and HA) by default, based on OpenFlow so it can be easy offloaded
> >    e.g. by SmartNICs;
> > * Distributed DHCP;
> > 
> > There are some feature parity gaps when comparing it to ML2/OVS that we
> > plan to address.  See [2] for details.
> > 
> > We think that merging this code into the neutron repository will help to
> > grow the networking-ovn community and will help us to keep a healthy
> > Neutron team as well by increasing the number or contributors.
> > 
> > Our current plan is to start merging code from networking-ovn into the
> > neutron repository as soon as possible in the Ussuri cycle.  But we also
> > wanted to get any additional opinions from the wider community about
> > this plan.  What do users and operators of Neutron think about this?
> 
> I'm very much supportive of something like this.  The most important thing
> is figuring out a proper migration path for those that are sitting on ML2/OVS,
> the last time I had a look at this, it wasn't very straightforward AFAIK.
you should in theory be able to live migration now which did not work before
although when i tried live migrating between ml2/ovs and ml2/linux bridge i found
issues so we would need to test ml2/ovs and ml2/ovn and fix any issue we find.
the main issue i see is the ovn use geneve as it default segmentaiton type
where as ml2/ovs mainly uses vlan,vxlan and to a lesser degre gre.

so without adding support for vxlan and gre network types to ovn you would have to change
the segmentation type of the existing networks in the db which is an action not supported
via the api. i know there is vxaln support ofr external vtep gateway in ovn but its not supproted
for tenant networks as far as i know.

the other complicaton is that different ml2 drivers do not form mesh networks between each other

so even if you used vxlan or genve on both ml2/ovs and ml2/ovn it wont give network connectivity.

i know there are migration sripts that kind of allow you to do this as an offline migraton between backends
but i dont think there is a way to do this in a rolling fashion so effectivly you need to swap your entire cloud in one
go. that is less then ideal even if you can live with the feature gaps between ml2/ovs and ml2/ovn today.

with all that said ti woudl be nice to see progress in closing those gaps

i have also noted a number of other feature gaps in comments in the spec but i fell like its still proably incomplete.
> 
> > [1] https://opendev.org/openstack/networking-ovn
> > [2] https://review.opendev.org/#/c/658414/
> > [3] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored
> >      Lines 252 - 295
> > [4] https://etherpad.openstack.org/p/shanghai-ptg-ops-meetup
> >      Lines 62 - 69
> > 
> > Thanks for any feedback,
> > 
> > -Brian (and Slawek)
> > 
> 
>