Open Stack

On 09/24/2015 10:18 AM, Salvatore Orlando wrote:
>     One particular issue is that the project implements the ovsdb protocol
>     from scratch.  The ovs project provides a Python library for this.  Both
>     Neutron and networking-ovn use it, at least.  From some discussion, I've
>     gathered that the ovs Python library lacked one feature that was needed,
>     but has since been added because we wanted the same thing in
>     networking-ovn.
> 
> 
> My take here is that we don't need to use the whole implementation of
> networking-l2gw, but only the APIs and the DB management layer it exposes.
> Networking-l2gw provides a VTEP network gateway solution that, if you
> want, will eventually be part of Neutron's "reference" control plane.
> OVN provides its implementation; I think it should be possible to
> leverage networking-l2gw either by pushing an OVN driver there, or
> implementing the same driver in openstack/networking-ovn.

>From a quick look, it seemed like networking-l2gw was doing 2 things.

  1) Management of vtep switches themselves

  2) Management of connectivity between Neutron networks and VTEP
     gateways

I figured the implementation of #1 would be the same whether you were
using ML2+OVS, OVN, (or whatever else).  This part is not addressed in
OVN.  You point OVN at VTEP gateways, but it's expected you manage the
gateway provisioning some other way.

It's #2 that has a very different implementation.  For OVN, it's just
creating a row in OVN's northbound database.

or did I mis-interpret what networking-l2gw is doing?

>     The networking-l2gw route will require some pretty significant work.
>     It's still the closest existing effort, so I think we should explore it
>     until it's absolutely clear that it *can't* work for what we need.
> 
> 
> I would say that it is definitely not trivial but probably a bit less
> than "significant". abhraut from my team has done something quite
> similar for openstack/vmware-nsx [1]

but specific to nsx.  :(

Does it look like networking-l2gw could be a common API for what's
needed for NSX?

> 
> 
>     > OR
>     >
>     > Should OVN pursue it’s own Neutron extension (including vtep gateway
>     > support).
> 
>     I don't think this option provides a lot of value over the short term
>     binding:profile solution.  Both are OVN specific.  I think I'd rather
>     just stick to binding:profile as the OVN specific stopgap because it's a
>     *lot* less work.
> 
> 
> I totally agree. The solution based on the binding profile is indeed a
> decent one in my opinion.
> If OVN cannot converge on the extension proposed by networking-l2gw then
> I'd keep using the binding profile for specifying gateway ports.

Great, thanks for the feedback!

> [1] https://review.openstack.org/#/c/210623/

-- 
Russell Bryant