Open Stack

It's already away from the original thread, so I start this new one,
also with some extra tag because I think it touch some corss-project
area.

Original discuss and reference:
http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html
https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst

Background summary:
All in-tree implementation would be splitted from Openstack
networking, leaving Neutron as a naked "API/DB" platform, with a list
of out-tree implementation git repos, which are not maintained by core
team any more, but may be given a nominal "big tent" under the
Openstack umbrella.

Motivation: a) Smaller core team only focus on the in-tree API/DB
definition, released from concrete controlling function
implementation; b) If there is official implementation inside Neutron,
3rd external SDN controller would face the competition.

I'm not sure whether it's exactly what cloud operators want the
Openstack to deliver. Do they want a off-the-shelf package, or just a
framework and have to take the responsibility of integrating with
other external controlling projects? A analogy with Linux that only
kernel without any device driver has no use at all.

There are already many debates about nova-network to Neutron parity.
If largely used OVS and LB driver is out of tree and has to be
integrated separately by customers, how do those they migrate from
nova network? Standalone SDN controller has steep learning curve, and
a lot of users don't care which one is better of ODL vs. OpenContrail
to be integrated, they just want Openstack package easy to go by
default in tree implementation,  and are ready to drive all kinds of
opensource or commercial backends.

BTW: +1 to henry and mathieu, that indeed Openstack is not responsible
projects of switch/router/fw, but it should be responsible for
scheduling, pooling, and driving of those backends, which is the same
case with Nova/Cinder scheduler and compute/volume manager. These
controlling functions shouldn't be classified as backends in Neutron
and be splitted out of tree.

Regards


On Fri, Apr 24, 2015 at 2:37 AM, Kyle Mestery <mestery at mestery.com> wrote:
>
>
> On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>>
>> Yeah. In the end, its what git repo the source for a given rpm you install
>> comes from. Ops will not care that neutron-openvswitch-agent comes from repo
>> foo.git instead of bar.git.
>>
>
>
> That's really the tl;dr of the proposed split.
>
> Thanks,
> Kyle
>
>>
>> Thanks,
>> Kevin
>> ________________________________
>> From: Armando M. [armamig at gmail.com]
>> Sent: Thursday, April 23, 2015 9:10 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend
>> code
>>
>>>>
>>> I agree with henry here.
>>> 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.
>>> 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.
>>> At the end of the day, it might be detrimental for the neutron project.
>>>
>>
>>
>> I don't think that anyone is saying that cloud admins are going to be
>> forced to deploy and maintain an external SDN controller. There are plenty
>> of deployment examples where people are just happy with network
>> virtualization the way Neutron has been providing for years and we should
>> not regress on that. To me it's mostly a matter of responsibilities of who
>> develops what, and what that what is :)
>>
>> The consumption model is totally a different matter.
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>