On 09/24/2015 01:25 PM, Armando M. wrote: > > > > On 24 September 2015 at 09:12, Russell Bryant <rbry...@redhat.com > <mailto: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).
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 __________________________________________________________________________ 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