<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe <span dir="ltr"><<a href="mailto:loywolfe@gmail.com" target="_blank">loywolfe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's already away from the original thread, so I start this new one,<br>
also with some extra tag because I think it touch some corss-project<br>
area.<br>
<br>
Original discuss and reference:<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html</a><br>
<a href="https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst" target="_blank">https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst</a><br>
<br>
Background summary:<br>
All in-tree implementation would be splitted from Openstack<br>
networking, leaving Neutron as a naked "API/DB" platform, with a list<br>
of out-tree implementation git repos, which are not maintained by core<br>
team any more, but may be given a nominal "big tent" under the<br>
Openstack umbrella.<br>
<br></blockquote><div> </div><div>I'm not sure what led you to this discussion, but it's patently incorrect. We're going to split the in-tree reference implementation into a separate git repository. I have not said anything about the current core revewier team not being responsible for that. It's natural to evolve to a core reviewer team which cares deeply about that, vs. those who care deeply about the DB/API layer. This is exactly what happened when we split out the advanced services.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Motivation: a) Smaller core team only focus on the in-tree API/DB<br>
definition, released from concrete controlling function<br>
implementation; b) If there is official implementation inside Neutron,<br>
3rd external SDN controller would face the competition.<br>
<br>
I'm not sure whether it's exactly what cloud operators want the<br>
Openstack to deliver. Do they want a off-the-shelf package, or just a<br>
framework and have to take the responsibility of integrating with<br>
other external controlling projects? A analogy with Linux that only<br>
kernel without any device driver has no use at all.<br>
<br></blockquote><div> </div><div>We're still going to deliver ML2+OVS/LB+[DHCP, L3, metadata] agents for Liberty. I'm not sure where your incorrect assumption on what we're going to deliver is coming from.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are already many debates about nova-network to Neutron parity.<br>
If largely used OVS and LB driver is out of tree and has to be<br>
integrated separately by customers, how do those they migrate from<br>
nova network? Standalone SDN controller has steep learning curve, and<br>
a lot of users don't care which one is better of ODL vs. OpenContrail<br>
to be integrated, they just want Openstack package easy to go by<br>
default in tree implementation, and are ready to drive all kinds of<br>
opensource or commercial backends.<br>
<br></blockquote><div> </div><div>Do you realize that ML2 is plus the L2 agent is an SDN controller already?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW: +1 to henry and mathieu, that indeed Openstack is not responsible<br>
projects of switch/router/fw, but it should be responsible for<br>
scheduling, pooling, and driving of those backends, which is the same<br>
case with Nova/Cinder scheduler and compute/volume manager. These<br>
controlling functions shouldn't be classified as backends in Neutron<br>
and be splitted out of tree.<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regards<br>
<br>
<br>
On Fri, Apr 24, 2015 at 2:37 AM, Kyle Mestery <<a href="mailto:mestery@mestery.com">mestery@mestery.com</a>> wrote:<br>
><br>
><br>
> On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
>><br>
>> Yeah. In the end, its what git repo the source for a given rpm you install<br>
>> comes from. Ops will not care that neutron-openvswitch-agent comes from repo<br>
>> foo.git instead of bar.git.<br>
>><br>
><br>
><br>
> That's really the tl;dr of the proposed split.<br>
><br>
> Thanks,<br>
> Kyle<br>
><br>
>><br>
>> Thanks,<br>
>> Kevin<br>
>> ________________________________<br>
>> From: Armando M. [<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>]<br>
>> Sent: Thursday, April 23, 2015 9:10 AM<br>
>> To: OpenStack Development Mailing List (not for usage questions)<br>
>> Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend<br>
>> code<br>
>><br>
>>>><br>
>>> I agree with henry here.<br>
>>> Armando, If we use your analogy with nova that doesn't build and deliver<br>
>>> KVM, we can say that Neutron doesn't build or deliver OVS. It builds a<br>
>>> driver and an agent which manage OVS, just like nova which provides a driver<br>
>>> to manage libvirt/KVM.<br>
>>> Moreover, external SDN controllers are much more complex than Neutron<br>
>>> with its reference drivers. I feel like forcing the cloud admin to deploy<br>
>>> and maintain an external SDN controller would be a terrible experience for<br>
>>> 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>
>>><br>
>><br>
>><br>
>> I don't think that anyone is saying that cloud admins are going to be<br>
>> forced to deploy and maintain an external SDN controller. There are plenty<br>
>> of deployment examples where people are just happy with network<br>
>> virtualization the way Neutron has been providing for years and we should<br>
>> not regress on that. To me it's mostly a matter of responsibilities of who<br>
>> develops what, and what that what is :)<br>
>><br>
>> The consumption model is totally a different matter.<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>
</blockquote></div><br></div></div>