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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
