Moshe Levi wrote:
-----Original Message-----
From: Sean M. Collins [mailto:s...@coreitpro.com]
Sent: Thursday, October 01, 2015 6:42 PM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] New cycle started. What are you up
to, folks?
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.
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/bd07b74045d93c46483aa26
1b8686072d9b448e8
I think the decision should be based on where is the core code located.
So if SR-IOV, OVS ,Linux Bridge, Qos are still in the neutron core the neutron
devstack plugin
should know how to install them. If we will decide to move them to different
repos the
their devstack part should be moved as well.
That is correct. Eventually, we should either:
1) Move all neutron devstack code into a plugin
2) Or move the QoS bits back into devstack.
The decision to make QoS part of the core was because we're extending
core resources, and our final aim
is to make it available to all plugins ( here's where the final core
resource extension manager that Ihar
pointed out comes in place.)
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,
Sincerely, Sean, IMHO it doesn't make any sense to create a repository
uniquely for a devstack plugin
to enable a feature which is in the main repository. That's also broken.
Would you ask for a separate devstack plugin for l3 too?
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.
It's a good opportunity to refactor as we move, if "1" is a good
strategy, otherwise, and if you think
neutron-legacy is a mess, let's work on cleaning it up while at "2".
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*.
Hmm, I'm not sure I follow, so, if people need to tweak localrc in
extremis, that's even going
to be more painful from the user/developer perspective.
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
