On 1 October 2015 at 08:42, Sean M. Collins <s...@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 <s...@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. > IMO we can't make these statements otherwise what's the point in looking forward if all we do is base our actions on some _indelible_ past? As for the rest, I am gonna let this thread sink in a bit before I come up with a more elaborate answer that this thread deserves. > > 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. > > If we are not careful, the Neutron DevStack plugin will grow into the big > mess that neutron-legacy is. > > 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*. > > 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. > > /rant > > -- > Sean M. Collins > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev