<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 1 October 2015 at 08:42, Sean M. Collins <span dir="ltr"><<a href="mailto:sean@coreitpro.com" target="_blank">sean@coreitpro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 01, 2015 at 11:05:29AM EDT, Kyle Mestery wrote:<br>
> On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins <<a href="mailto:sean@coreitpro.com">sean@coreitpro.com</a>> wrote:<br>
><br>
> > On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:<br>
> > > - more changes with less infra tinkering! neutron devs should not need<br>
> > to go to infra projects so often to make an impact;<br>
</span>> > > -- make our little neat DevStack plugin used for qos and sr-iov only a<br>
> > huge pile of bash code that is currently stored in DevStack and is proudly<br>
<span class="">> > called neutron-legacy now; and make the latter obsolete and eventually<br>
</span>> > removed from DevStack;<br>
<span class="">> ><br>
> > We may need to discuss this. I am currently doing a refactor of the<br>
> > Neutron DevStack integration in<br>
> ><br>
> > <a href="https://review.openstack.org/168438" rel="noreferrer" target="_blank">https://review.openstack.org/168438</a><br>
> ><br>
> > If I understand your message correctly, I disagree that we should be<br>
> > moving all the DevStack support for Neutron out of DevStack and making<br>
> > it a plugin. All that does is move the mess from one corner of the room,<br>
> > to another corner.<br>
> ><br>
> ><br>
> I would actually be in favor of cleaning up the mess AND moving it into<br>
> neutron. If it's in Neutron, we control our own destiny with regards to<br>
</span>> landing patches which affect DevStack and ultimately our gate jobs. To me,<br>
<span class="">> that's a huge win-win. Thus, cleanup first, then move to Neutron.<br>
<br>
</span>Frankly we have a bad track record in DevStack, if we are to make an<br>
argument about controlling our own destiny. Neutron-lib is in a sad<br>
state of affairs because we haven't had the discipline to keep things<br>
simple.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In fact, I think the whole genesis of the Neutron plugin for DevStack is<br>
a great example of how controlling our own destiny has started to grow<br>
the mess. Yes, we needed it to gate the QoS code. But now things are<br>
starting to get added.<br>
<br>
<a href="https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa261b8686072d9b448e8" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa261b8686072d9b448e8</a><br>
<br>
The trend is now that people are going to throw things into the Neutron<br>
DevStack plugin to get their doo-dad up and running, because making a<br>
new repo is harder than creating a patch (which maybe shows are repo<br>
creation process needs streamlining). I was originally for making<br>
Neutron DevStack plugins that exist in their own repos, instead of<br>
putting them in the Neutron tree. At least that makes things small,<br>
manageable, and straight forward. Yes, it makes for more plugin lines in<br>
your DevStack configuration, but at least you know what each one does,<br>
instead of being an agglomeration.<br>
<br>
If we are not careful, the Neutron DevStack plugin will grow into the big<br>
mess that neutron-legacy is.<br>
<br>
Finally, Look at how many configuration knobs we have, and how there is<br>
a tendency to introduce new ones, instead of using local.conf to inject<br>
configuration into Neutron and the associated components. This ends up<br>
making it very complicated for someone to actually run Neutron in their<br>
DevStack, and I think a lot of people would give up and just run<br>
Nova-Network, which I will note is *still the default*.<br>
<br>
We need to keep our ties strong with other projects, and improve them in<br>
some cases. I think culturally, if we start trying to move things into<br>
our corner of the sandbox because working with other groups is hard, we<br>
send bad signals to others. This will eventually come back to bite us.<br>
<br>
/rant<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Sean M. Collins<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>