<div dir="ltr"><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 September 2015 at 09:12, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 09/24/2015 10:18 AM, Salvatore Orlando wrote:<br>
>     One particular issue is that the project implements the ovsdb protocol<br>
>     from scratch.  The ovs project provides a Python library for this.  Both<br>
>     Neutron and networking-ovn use it, at least.  >From some discussion, I've<br>
>     gathered that the ovs Python library lacked one feature that was needed,<br>
>     but has since been added because we wanted the same thing in<br>
>     networking-ovn.<br>
><br>
><br>
> My take here is that we don't need to use the whole implementation of<br>
> networking-l2gw, but only the APIs and the DB management layer it exposes.<br>
> Networking-l2gw provides a VTEP network gateway solution that, if you<br>
> want, will eventually be part of Neutron's "reference" control plane.<br>
> OVN provides its implementation; I think it should be possible to<br>
> leverage networking-l2gw either by pushing an OVN driver there, or<br>
> implementing the same driver in openstack/networking-ovn.<br>
<br>
</span>From a quick look, it seemed like networking-l2gw was doing 2 things.<br>
<br>
  1) Management of vtep switches themselves<br>
<br>
  2) Management of connectivity between Neutron networks and VTEP<br>
     gateways<br>
<br>
I figured the implementation of #1 would be the same whether you were<br>
using ML2+OVS, OVN, (or whatever else).  This part is not addressed in<br>
OVN.  You point OVN at VTEP gateways, but it's expected you manage the<br>
gateway provisioning some other way.<br>
<br>
It's #2 that has a very different implementation.  For OVN, it's just<br>
creating a row in OVN's northbound database.<br>
<br>
or did I mis-interpret what networking-l2gw is doing?<br></blockquote><div><br></div><div>No, you did not misinterpret what the objective of the project were (which I reinstate here):</div><div><br></div><div>* 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.</div><div><br></div><div>* Provide a pluggable framework for multiple drivers of the API.</div><div><br></div><div>* 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). </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
>     The networking-l2gw route will require some pretty significant work.<br>
>     It's still the closest existing effort, so I think we should explore it<br>
>     until it's absolutely clear that it *can't* work for what we need.<br></span></blockquote><div><br></div><div>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.</div><div><br></div><div>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 <span style="font-size:12.8px">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.</span></div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
><br>
><br>
> I would say that it is definitely not trivial but probably a bit less<br>
> than "significant". abhraut from my team has done something quite<br>
> similar for openstack/vmware-nsx [1]<br>
<br>
</span>but specific to nsx.  :(<br>
<br>
Does it look like networking-l2gw could be a common API for what's<br>
needed for NSX?<br>
<span class=""><br>
><br>
><br>
>     > OR<br>
>     ><br>
>     > Should OVN pursue it’s own Neutron extension (including vtep gateway<br>
>     > support).<br>
><br>
>     I don't think this option provides a lot of value over the short term<br>
>     binding:profile solution.  Both are OVN specific.  I think I'd rather<br>
>     just stick to binding:profile as the OVN specific stopgap because it's a<br>
>     *lot* less work.<br>
><br>
><br>
> I totally agree. The solution based on the binding profile is indeed a<br>
> decent one in my opinion.<br>
> If OVN cannot converge on the extension proposed by networking-l2gw then<br>
> I'd keep using the binding profile for specifying gateway ports.<br>
<br>
</span>Great, thanks for the feedback!<br>
<br>
> [1] <a href="https://review.openstack.org/#/c/210623/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/210623/</a><br>
<div class=""><div class="h5"><br>
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>