Open Stack

On 24 April 2015 at 15:13, 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.
>

This discussion seems quite similar to that we had about non-reference
plugins.
Following the linux analogy you mention below Neutron should have been
deprived of its plugins and drivers. And indeed, regardless of what it
seems, it hasn't. Any user can still grab drivers as before. They just
reside in different repos. This is not different, imho, from the concept of
maintainers that linux has.
Besides you make it look at like as if the management layer (API/DB) is
just a tiny insignificant piece of software. I disagree quite strongly
here, but perhaps it's just me seeing in Neutron's mgmt layer something
more than what is actually is.


>
>
>> 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.
>>
>
Perhaps point (b) is a bit unclear. Are you stating that having this
control plane in Neutron gives it a "better placement" compared with other
solutions?


>
>> 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.
>

I would answer with a different analogy - nova. Consider the various agents
as if it were libvirt. Like libvirt is a component which you use to control
your hypervisor, the agents control the data plane (OVS and utilities like
iptables/conntrack/dnsmasq/etc). With this analogy I believe Neutron's
"reference" control plane deserves to live on its own, just like nobody
would ever think that a libvirt implementation within nova is something
sane,
However, ML2 is a different beast. It has inside management and control
logic, we'll need a good surgeon there. Pretty sure our refactoring fans
are already drooling at the thought of cutting apart another component.


>
>
>> 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.
>>
>
I'm not sure what you mean here. In your opinions do operator want
something that works and provides everything out of the box, and want
something which is able to driver open source and commercial backends.
And besides I do not see the complication from operators arising from this
proposal. It's not like they have to maintain another component - indeed
from an operator perspective l3 agents, dhcp agents, and so on are already
different components to maintain (and that's one of the pain points they
feel in using neutron)

>
>>
> Do you realize that ML2 is plus the L2 agent is an SDN controller already?
>
>
>> 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
>>
>
Thanks for your comments Loy. Every time you chime on the mailing list you
always have detailed insights.
Can I ask your IRC handle so that we can follow up on IRC? I could not find
it since you appear to not have a gerrit account, or a launchpad id, or a
foundation profile for that matter.

Regards,
Salvatore


>>
>> 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/2af4b93d/attachment.html>