<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">+1<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF304619"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Armando M. [armamig@gmail.com]<br>
<b>Sent:</b> Wednesday, April 22, 2015 7:44 PM<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<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
</div>
</div>
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>
</blockquote>
<div><br>
</div>
<div>I think the analogy here is between the agent reference implementation vs KVM or Ceph, rather than the plumbing that taps into the underlying technology. Nova doesn't build/package KVM as Cinder doesn't build/package Ceph. Neutron could rely on other open
source solutions (ODL, OpenContrail, OVN, etc), and still be similar to the other projects.</div>
<div><br>
</div>
<div>I think there's still room for clarifying what the split needs to be, but I have always seen Neutron as the exception rather than norm, where, for historic reasons, we had to build everything from the ground up for lack of viable open source solutions
at the time the project was conceived.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<br>
[1a] <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>
<div class="HOEnZb">
<div class="h5"><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 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 far<br>
> to warrant an entirely new project, PTL and infra around it. This is 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 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 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 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>
>> <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>
>> <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>
>> <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>
>> 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>
</body>
</html>