Open Stack

On 09/24/2015 01:25 PM, Armando M. wrote:
> 
> 
> 
> On 24 September 2015 at 09:12, Russell Bryant <rbryant at redhat.com
> <mailto:rbryant at redhat.com>> wrote:
> 
>     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?
> 
> 
> No, you did not misinterpret what the objective of the project were
> (which I reinstate here):
> 
> * Provide an API to OpenStack admins to extend neutron logical networks
> into unmanaged pre-existing vlans. Bear in mind that things like address
> collision prevention is left in the hands on the operator. Other aspects
> like L2/L3 interoperability instead should be taken care of, at least
> from an implementation point of view.
> 
> * Provide a pluggable framework for multiple drivers of the API.
> 
> * Provide an PoC implementation on top of the ovsdb vtep schema. This
> can be implemented both in hardware (ToR switches) and software
> (software L2 gateways). 

Thanks for clarifying the project's goals!

>     >     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.
> 
> 
> We may have fallen short of some/all expectations, but I would like to
> believe than it is nothing that can't be fixed by iterating on,
> especially if active project participation raises.
> 
> I don't think there's a procedural mandate to make OVN abide by the l2gw
> proposed API. As you said, it is not a clear well accepted API, but
> that's only because we live in a brand new world, where people should be
> allowed to experiment and reconcile later as community forces play out.
> 
> That said, should the conclusion that "it (the API) *can't* work for
> what OVN needs" be reached, I would like to understand/document why for
> the sake of all us involved so that lessons will yield from our mistakes.

My gut says we should be able to work together and make it work.  I
expect we'll talk in more detail in the next cycle.  :-)

-- 
Russell Bryant