<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 28, 2015 at 12:17 PM, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Apologies for commenting so late, but I'm not clear on the concept of bringing all possible backend projects back inside Neutron.</p>
<p><br>
</p>
<p>I think my question is similar to what Henry and Mathieu are getting at below - viz:</p>
<p><br>
</p>
<p>We just recently decided to move a lot of vendor-specific ML2 mechanism driver code _out_ of the Neutron tree; and I thought that the main motivation for that was that it wasn't reasonably possible for most Neutron developers to understand, review and maintain
 that code to the same level as they can with the Neutron core code.</p>
<p><br>
</p>
<p>How then does it now make sense to bring a load of vendor-specific code back into the Neutron fold?  Has some important factor changed?  Or have I misunderstood what is now being proposed?</p>
<p><br></p></div></div></blockquote><div><br></div><div>I think you're confusing where the code lives with which core team reviews it and merges code. The reason for moving the backend logic code out was so the respective vendor or open source team could review and merge code in those trees. What we're talking about here is where those repositories live. They would not fall under the neutron core review team. They would simply defer to being governed by OpenStack governance, namely the Neutron PTL.<br><br></div><div>Thanks,<br></div><div>Kyle <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><p>
</p>
<p>Many thanks,</p>
<p>    Neil</p>
<p><br>
</p>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Mathieu Rohon <<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>><br>
<b>Sent:</b> 23 April 2015 15:05<span class=""><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code</span></font>
<div> </div>
</div>
<div>
<div dir="ltr"><br><div><div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Apr 23, 2015 at 10:28 AM, henry hly <span dir="ltr">
<<a href="mailto:henry4hly@gmail.com" target="_blank">henry4hly@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>On Thu, Apr 23, 2015 at 10:44 AM, Armando M. <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<br>
>><br>
>> Could you please also pay some attention on Cons of this ultimate<br>
>> splitting Kyle? I'm afraid it would hurt the user experiences.<br>
>><br>
>> On the position of Dev, A naked Neutron without "official" built-in<br>
>> reference implementation probably has a more clear architecture. On<br>
>> the other side, users would be forced to make choice between a long<br>
>> list of backend implementations, which is very difficult for<br>
>> non-professionals.<br>
>><br>
>> In most of the time, users need a off-the-shelf solution without<br>
>> paying much extra integration effort, and they have less interest to<br>
>> study which SDN controller is powerful and is better than others. Can<br>
>> we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM<br>
>> volume driver [See Deployment Profiles section in 1a] ? Shall we<br>
>> really decide to make Neutron the only Openstack project which has not<br>
>> any in tree official implementation?<br>
><br>
><br>
> I think the analogy here is between the agent reference implementation vs<br>
> KVM or Ceph, rather than the plumbing that taps into the underlying<br>
> technology. Nova doesn't build/package KVM as Cinder doesn't build/package<br>
> Ceph. Neutron could rely on other open source solutions (ODL, OpenContrail,<br>
> OVN, etc), and still be similar to the other projects.<br>
><br>
> I think there's still room for clarifying what the split needs to be, but I<br>
> have always seen Neutron as the exception rather than norm, where, for<br>
> historic reasons, we had to build everything from the ground up for lack of<br>
> viable open source solutions at the time the project was conceived.<br>
><br>
<br>
</span>Thanks for bring in this interesting topic, maybe it should not be<br>
scoped only inside Neutron, also I found a similar discuss from John<br>
griffith on Cinder vs SDS controller :-)<br>
<br>
<a href="https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/" target="_blank">https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/</a><br>
<br>
It's clear that an typical Cloud deployment is composed of two<br>
distinct part: workload engine vs. supervisor. The engine part<br>
obviously do not belong to Openstack project, which include open<br>
sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's<br>
like Vcenter/ESXi, SAN disk arrays, and all kinds of networking<br>
hardware gears or virtualized service VMs.<br>
<br>
However for the supervisor part, there is some blurring for debates:<br>
Should Openstack provide complete in-house implementation of<br>
controlling functions which could directly drive backend workload<br>
engine (via backend driver), or just thin API/DB layer which need to<br>
integrate some 3rd external controller projects to finish those works:<br>
scheduling, pooling and service logic abstraction? For networking, how<br>
should we regard the functions of plugin/agent and SDN controller, are<br>
they classified in the same layer of "real" backends working engine<br>
like Switchs/Routers/Firewalls?<br>
<br>
For Nova & Cinder, it seems former is adopted: a single unified<br>
central framework including API, scheduling, abstraction service<br>
logic, rpc & message queue, and a common agent side framework of<br>
compute/volume manager, then with a bunch of virt/volume drivers<br>
plugged to abstract the all kinds of backends. There are standalone<br>
backends like KVM and LVM, and aggregated clustering backends like<br>
vcenter and ceph.<br>
<br>
The Neutron was just like a developing game of continuously<br>
re-factoring: plugin, meta plugin, ML2, and now the "platform". Next<br>
ML2 plugin suddenly became just a "reference" for concept proving, and<br>
no plugin/agent would be maintained in-tree officially anymore, while<br>
the reason is confusingly "not to compete with other 3rd SDN<br>
controllers" :-P<br>
<div>
<div></div>
</div>
</blockquote>
<div><br>
</div>
<div>I agree with henry here. <br>
</div>
<div>Armando, If we use your analogy with nova that doesn't build and deliver KVM, we can say that Neutron doesn't build or deliver OVS. It builds a driver and an agent which manage OVS, just like nova which provides a driver to manage libvirt/KVM.<br>
</div>
<div>Moreover, external SDN controllers are much more complex than Neutron with its reference drivers. I feel like forcing the cloud admin to deploy and maintain an external SDN controller would be a terrible experience for him if he just needs a simple way
 manage connectivity between VMs.<br>
At the end of the day, it might be detrimental for the neutron project.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>><br>
>><br>
>><br>
>> [1a]<br>
>> <a href="http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014" target="_blank">
http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014</a><br>
>><br>
>> Here is my personal suggestion: decomposition decision needs some<br>
>> trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2<br>
>> with OVS&LB, based on the survey result of 1a above]. While we are<br>
>> progressing radically with architecture re-factoring, smooth<br>
>> experience and easy to adoption should also be cared.<br>
>><br>
>> ><br>
>> > One thing which is worth bringing up in this context is the potential<br>
>> > overlap between this implementations. I think having them all under the<br>
>> > Neutron project would allow me as PTL and the rest of the team work to<br>
>> > combine things when it makes sense.<br>
>> ><br>
>> > Kyle<br>
>> ><br>
>> > [1] <a href="http://www.faqs.org/rfcs/rfc1149.html" target="_blank">http://www.faqs.org/rfcs/rfc1149.html</a><br>
>> ><br>
>> >><br>
>> >> b) Let each interested group define a new project team for their<br>
>> >> backend<br>
>> >> code.<br>
>> >><br>
>> > To be honest, I don't this is a scalable option. I'm involved with 2 of<br>
>> > these networking-foo projects, and there is not enough participation so<br>
>> > far<br>
>> > to warrant an entirely new project, PTL and infra around it. This is<br>
>> > just my<br>
>> > opinion, but it's an opinion I've taken after having contributed to<br>
>> > networking-odl and networking-ovn for the past 5 months.<br>
>> ><br>
>> >><br>
>> >> So, as an example, the group of people working on Neutron integration<br>
>> >> with OpenDaylight could propose a new project team that would be a<br>
>> >> projects.yaml entry that looks something like:<br>
>> >><br>
>> >> Neutron-OpenDaylight:<br>
>> >>   ptl: Some Person (ircnick)<br>
>> >>   service: OpenDaylight Networking<br>
>> >>   mission: ><br>
>> >>     To implement Neutron support for the OpenDaylight project.<br>
>> >>   url: ...<br>
>> >>   projects:<br>
>> >>     - repo: openstack/networking-odl<br>
>> >><br>
>> >> Pros:<br>
>> >>  + There's no additional load on the Neutron project team and PTL.<br>
>> >><br>
>> >> Cons:<br>
>> >>  - Having all of these efforts organized under a single project team<br>
>> >> and<br>
>> >> PTL might be better for ensuring some level of collaboration and<br>
>> >> consistency.<br>
>> >><br>
>> >> c) A single new project team could be created that is led by a single<br>
>> >> person to coordinate the sub-teams working on each repo.  In this<br>
>> >> scenario, I could see the overall collaboration being around ensuring<br>
>> >> consistent approaches to development process, testing, documentation,<br>
>> >> and releases.<br>
>> >><br>
>> >> That would be something like this (note that the project list would be<br>
>> >> limited to those who actually want to be included in the official<br>
>> >> project team and meet some set of inclusion criteria).<br>
>> >><br>
>> >> Neutron-Backends:<br>
>> >>   ptl: Some Person (ircnick)<br>
>> >>   service: Networking Backends<br>
>> >>   mission: ><br>
>> >>     To implement Neutron backend support for various networking<br>
>> >>     technologies.<br>
>> >>   url: ...<br>
>> >>   projects:<br>
>> >>     - openstack/networking-arista<br>
>> >>     - openstack/networking-bagpipe-l2<br>
>> >>     - openstack/networking-bgpvpn<br>
>> >>     - openstack/networking-bigswitch<br>
>> >>     - openstack/networking-brocade<br>
>> >>     - openstack/networking-cisco<br>
>> >>     - openstack/networking-edge-vpn<br>
>> >>     - openstack/networking-hyperv<br>
>> >>     - openstack/networking-ibm<br>
>> >>     - openstack/networking-l2gw<br>
>> >>     - openstack/networking-midonet<br>
>> >>     - openstack/networking-mlnx<br>
>> >>     - openstack/networking-nec<br>
>> >>     - openstack/networking-odl<br>
>> >>     - openstack/networking-ofagent<br>
>> >>     - openstack/networking-ovn<br>
>> >>     - openstack/networking-ovs-dpdk<br>
>> >>     - openstack/networking-plumgrid<br>
>> >>     - openstack/networking-portforwarding<br>
>> >>     - openstack/networking-vsphere<br>
>> >><br>
>> >> Pros:<br>
>> >>  + There's no additional load on the Neutron project team and PTL.<br>
>> >>  + Avoids a proliferation of new project teams for each Neutron<br>
>> >> backend.<br>
>> >>  + Puts efforts under a single team and PTL to help facilitate<br>
>> >> collaboration and consistency.<br>
>> >><br>
>> >> Cons:<br>
>> >>  - Some might see this as an unnatural split from Neutron.<br>
>> >>  - The same sort of oversight and coordination could potentially happen<br>
>> >> with a delegate of the Neutron PTL in the Neutron project team without<br>
>> >> making it separate.<br>
>> >><br>
>> >> d) I suppose the last option is to declare that none of these repos<br>
>> >> make<br>
>> >> sense as an OpenStack project.  It's hard for me to imagine this making<br>
>> >> sense except for cases where the teams don't want their work to be<br>
>> >> officially included in OpenStack, or they fail to meet our base set of<br>
>> >> project guidelines.<br>
>> >><br>
>> >><br>
>> >> What option do you think makes sense?  Or is there another option that<br>
>> >> should be considered?<br>
>> >><br>
>> >><br>
>> >> [1]<br>
>> >><br>
>> >> <a href="http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/" target="_blank">
http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/</a><br>
>> >> [2]<br>
>> >><br>
>> >><br>
>> >> <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html" target="_blank">
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html</a><br>
>> >> [3]<br>
>> >><br>
>> >><br>
>> >> <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html" target="_blank">
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html</a><br>
>> >> [4] <a href="http://governance.openstack.org/reference/tags/" target="_blank">
http://governance.openstack.org/reference/tags/</a><br>
>> >><br>
>> >> --<br>
>> >> Russell Bryant<br>
>> >><br>
>> >><br>
>> >> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div></div></div>
</div>
</div>
</div>
</div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>