On 24 September 2015 at 09:12, Russell Bryant <rbry...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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
