Open Stack

Hi loy, thanks for this dedicated thread.

On Fri, Apr 24, 2015 at 3:13 PM, Kyle Mestery <mestery at mestery.com> wrote:

> On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe <loywolfe at gmail.com> wrote:
>
>> 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.
>>
>>
> 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.
>
>
>> 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.
>>
>>
> 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.
>
>
>> 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.
>>
>>
> Do you realize that ML2 is plus the L2 agent is an SDN controller already?
>

I totally agree that this part of Neutron should be considered as a SDN
controller. Actually we can even say that the Neutron SDN controller is
composed of ML2+ref service plugins+agents.
I think this thread is also motivated by the fact that, during design
summit,  we keep on earing that Neutron should NOT deliver and maintain a
SDN controller, and it should rely on 3rd party SDN controllers.


>
>> 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
>> >
>>
>> __________________________________________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/8f3dd762/attachment.html>