<div dir="ltr">Random comments inline.<div><br></div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 24 September 2015 at 14:05, 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 01:17 AM, Amitabha Biswas wrote:<br>
> Hi everyone,<br>
><br>
> I want to open up the discussion regarding how to support OVN<br>
> VTEP gateway deployment and its lifecycle in Neutron.<br>
<br>
</span>Thanks a lot for looking into this!<br>
<span class=""><br>
> In the "Life Cycle of a VTEP gateway" part in the OVN architecture<br>
> document (<a href="http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf" rel="noreferrer" target="_blank">http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf</a>),<br>
> step 3 is where the Neutron OVN plugin is involved. At a minimum, the<br>
> Neutron OVN plugin will enable setting the type as "vtep" and the<br>
> vtep-logical-switch and vtep-physical-switch options in the<br>
> OVN_Northbound database.<br>
<br>
</span>I have the docs published there just to make it easier to read the<br>
rendered version.  The source of that document is:<br>
<br>
<a href="https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml" rel="noreferrer" target="_blank">https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml</a><br>
<span class=""><br>
> There are 2 parts to the proposal/discussion - a short term solution and<br>
> a long term one:<br>
><br>
> A short term solution (proposed by Russell Bryant) is similar to the<br>
> work that was done for container support in OVN - using a binding<br>
> profile <a href="http://networking-ovn.readthedocs.org/en/latest/containers.html" rel="noreferrer" target="_blank">http://networking-ovn.readthedocs.org/en/latest/containers.html</a>.<br>
> A ovn logical network/switch can be mapped to a vtep logical gateway by<br>
> creating a port in that logical network and creating a binding profile<br>
> for that port in the following manner:<br>
><br>
> neutron port-create --binding-profile<br>
> '{"vtep-logical-switch":"vtep_lswitch_key",<br>
> "vtep-physical-switch":"vtep_pswitch_key"}' private.<br>
><br>
> Where vtep-logical-switch and vtep-physical-switch should have been<br>
> defined in the OVN_Southbound database by the previous steps (1,2) in<br>
> the life cycle.<br>
<br>
</span>Yes, this sounds great to me.  Since there's not a clear well accepted<br>
API to use, we should go this route to get the functionality exposed<br>
more quickly.  We should also include in our documentation that this is<br>
not expected to be how this is done long term.<br>
<br>
The comparison to the containers-in-VMs support is a good one.  In that<br>
case we used binding:profile as a quick way to expose it, but we're<br>
aiming to support a proper API.  For that feature, we've identified the<br>
"VLAN aware VMs" API as the way forward, which will hopefully be<br>
available next cycle.<br>
<span class=""><br>
> For the longer term solution, there needs to be a discussion:<br>
><br>
> Should the knowledge about the physical and logical step gateway should<br>
> be exposed to Neutron - if yes how? This would allow a Neutron NB<br>
> API/extension to bind a “known” vtep gateway to the neutron logical<br>
> network. This would be similar to the workflow done in the<br>
> networking-l2gw extension<br>
> <a href="https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst</a><br>
><br>
> 1. Allow the admin to define and manage the vtep gateway through Neutron<br>
> REST API.<br>
><br>
> 2. Define connections between Neutron networks and gateways. This is<br>
> conceptually similar to Step 3 of the step gateway performed by the OVN<br>
> Plugin in the short term solution.<br>
<br>
</span>networking-l2gw does seem to be the closest thing to what's needed, but<br>
it's not a small amount of work.  I think the API might need to be<br>
extended a bit for our needs.  A bigger concern for me is actually with<br>
some of the current implementation details.<br></blockquote><div><br></div><div>It is indeed. While I like very much the solution based on binding profiles it does not work very well from a UX perspective in environments where operators control the whole cloud with openstack tools.</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">
<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 networking-ovn.<br></blockquote><div><br></div><div>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.</div><div>Networking-l2gw provides a VTEP network gateway solution that, if you want, will eventually be part of Neutron's "reference" control plane.</div><div>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.</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">
<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></blockquote><div><br></div><div>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]</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>
> OR<br>
><br>
> Should OVN pursue it’s own Neutron extension (including vtep gateway<br>
> support).<br>
<br>
</span>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></blockquote><div><br></div><div>I totally agree. The solution based on the binding profile is indeed a decent one in my opinion.</div><div>If OVN cannot converge on the extension proposed by networking-l2gw then I'd keep using the binding profile for specifying gateway ports.</div><div><br></div><div><div>[1] <a href="https://review.openstack.org/#/c/210623/">https://review.openstack.org/#/c/210623/</a></div><div> <br></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">
<br>
Thanks again,<br>
<span class=""><font color="#888888"><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>
</font></span></blockquote></div><br></div></div></div>