<div dir="ltr"><br><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 class="">On Thu, Apr 23, 2015 at 10:44 AM, Armando M. <<a href="mailto:armamig@gmail.com">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 class="HOEnZb"><div class="h5"></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 class="HOEnZb"><div class="h5">
><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>