Open Stack

On Fri, Apr 24, 2015 at 9:46 PM, Salvatore Orlando <sorlando at nicira.com> wrote:
>
>
> 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?
>

The words are just from the reference split spec :)

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

At least for me and most of out customers, deployment and maintenance
of openstack and ODL together with its SDN apps had taken much more
effort than native Neutron ML2+agents. However existing agents need to
evolve as you mentioned, e.g. modular combined agents

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

Sorry strictly speaking I'm not a developer, so have no gerrit account
yet. I'm a consultant to help people building and running openstack
more easily. However I will try with IRC if it is more convenient for
communication.

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