Open Stack

On 24 September 2015 at 09:12, Russell Bryant <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).



>
> >     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.

>
> >
> > 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150924/25dbae37/attachment.html>