Open Stack

> On Oct 1, 2015, at 8:59 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> 
>> On 01 Oct 2015, at 17:42, Sean M. Collins <sean at coreitpro.com> wrote:
>> 
>> On Thu, Oct 01, 2015 at 11:05:29AM EDT, Kyle Mestery wrote:
>>> On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins <sean at coreitpro.com> wrote:
>>> 
>>>> On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:
>>>>> - more changes with less infra tinkering! neutron devs should not need
>>>> to go to infra projects so often to make an impact;
>>>>> -- make our little neat DevStack plugin used for qos and sr-iov only a
>>>> huge pile of bash code that is currently stored in DevStack and is proudly
>>>> called neutron-legacy now; and make the latter obsolete and eventually
>>>> removed from DevStack;
>>>> 
>>>> We may need to discuss this. I am currently doing a refactor of the
>>>> Neutron DevStack integration in
>>>> 
>>>> https://review.openstack.org/168438
>>>> 
>>>> If I understand your message correctly, I disagree that we should be
>>>> moving all the DevStack support for Neutron out of DevStack and making
>>>> it a plugin. All that does is move the mess from one corner of the room,
>>>> to another corner.
>>>> 
>>>> 
>>> I would actually be in favor of cleaning up the mess AND moving it into
>>> neutron. If it's in Neutron, we control our own destiny with regards to
>>> landing patches which affect DevStack and ultimately our gate jobs. To me,
>>> that's a huge win-win. Thus, cleanup first, then move to Neutron.
>> 
>> Frankly we have a bad track record in DevStack, if we are to make an
>> argument about controlling our own destiny. Neutron-lib is in a sad
>> state of affairs because we haven't had the discipline to keep things
>> simple.
>> 
>> In fact, I think the whole genesis of the Neutron plugin for DevStack is
>> a great example of how controlling our own destiny has started to grow
>> the mess. Yes, we needed it to gate the QoS code. But now things are
>> starting to get added.
>> 
>> https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa261b8686072d9b448e8
>> 
>> The trend is now that people are going to throw things into the Neutron
>> DevStack plugin to get their doo-dad up and running, because making a
>> new repo is harder than creating a patch (which maybe shows are repo
>> creation process needs streamlining). I was originally for making
>> Neutron DevStack plugins that exist in their own repos, instead of
>> putting them in the Neutron tree. At least that makes things small,
>> manageable, and straight forward. Yes, it makes for more plugin lines in
>> your DevStack configuration, but at least you know what each one does,
>> instead of being an agglomeration.
>> 
> 
> Scattering devstack plugins in separate repos that are far from the code that they actually try to manage seems to me like a huge waste of time and resources. Once a component is out of the tree, I agree their devstack pieces should go away too. But while we keep QoS or SR-IOV in the tree, I think it’s the right place to have all stuff related in.

This conversation should include the devstack folks, because they do have some concerns about splitting up too much, and thus making it harder to unwedge the gate. I lean towards all neutron devstack in the neutron repo myself, but that’s not a decision to be made in a vacuum.

What I’d like to see, given everything I’ve heard from everywhere, and just IMO:

- A *minimal* neutron support in native devstack, that basically provides the simplest nova-net/provider network/bare connectivity.
- All other neutron features that are in the neutron repo (tenant networking, qos, dvr), move into the neutron devstack plugin.
- Anything out of the neutron repo has its devstack support in its own repo (e.g. neutron-lbaas/devstack)

In other words, the devstack plugin lives in the repo that supports it.

Thanks,
doug


> 
>> If we are not careful, the Neutron DevStack plugin will grow into the big
>> mess that neutron-legacy is.
>> 
> 
> With your valuable reviewer comments, it has no way to come to such a pity state. ;)
> 
>> Finally, Look at how many configuration knobs we have, and how there is
>> a tendency to introduce new ones, instead of using local.conf to inject
>> configuration into Neutron and the associated components. This ends up
>> making it very complicated for someone to actually run Neutron in their
>> DevStack, and I think a lot of people would give up and just run
>> Nova-Network, which I will note is *still the default*.
>> 
> 
> local.conf is fine but I believe we should still hide predefined sets of configuration values that would define ‘roles’ like QoS or L3 or VPNaaS, under ‘services’ (like q-qos or q-sriov).
> 
> I don’t believe the number of non-default knobs is the issue that bothers people and make them use nova-network. The fact that default installation does not set up networking properly is the issue though.
> 
>> We need to keep our ties strong with other projects, and improve them in
>> some cases. I think culturally, if we start trying to move things into
>> our corner of the sandbox because working with other groups is hard, we
>> send bad signals to others. This will eventually come back to bite us.
> 
> Well, it seems that the general trend in -dev projects like devstack or grenade is to give projects a plugin interface and then push them into adopting their pieces of code thru that interface. I will merely note that for QoS, the initial idea was to introduce q-qos service into devstack, but devstack core team (reasonably) pushed us into plugin world. They forbid new features in grenade for the same reason, so that we have motivation to move out of tree.
> 
> Ihar
> __________________________________________________________________________
> 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