Open Stack

On 27 October 2016 at 22:18, Brandon Logan <brandon.logan at rackspace.com>
wrote:

> Hello Neutrinos,
> I've come across an issue that I'd like to get input/opinions on.  I've
> been reviewing some of the centralize config options reviews and have
> come across a few that would cause issues with other projects that are
> importing these options, especially stadium projects.  High level view
> of the issue:
>
> [1] would cause at least 22 projects to need to be fixed based on [2]
>
> [3] would cause at least 12 projects to need to be fixed based on [4]
>
> [5] looks to affect many other projects as well (I'm being lazy and
> not  counting them right now)
>
> Initially, the thinking was that moving the config options around would
> cause some breakage with projects outside of neutron, but that would be
> fine because projects shouldn't really be using neutron as a library
> and using it to register config options.  However, with these 3
> patches, I definitely don't feel comfortable breaking the amount of
> projects these would break.  It also makes me think that maybe these
> options should be in neutron-lib since they're consumed so widely.
> Anyway, I've come up with some possible options to deal with this, but
> would like to hear others' opinions on this:
>
> 1) Let the patches merge and break those projects as a signal that
> importing these shouldn't be done.  The affected projects can choose to
> push fixes that continue importing the neutron config options or
> defining their own config options.
> 2) Deprecate the old locations for some timeframe, and then remove
> later.
> 3) Texas Three-Step: change the neutron patches to keep pointers in the
> old locations to the new, and then push patches to the affected repos
> with Depends-On directives.  Once all patches merge, push up one more
> patch to neutron to remove the old location.
> 4) Abandon these reviews and do nothing.
> 5) Move these config options to neutron-lib so that they can be used by
> any project.  This still requires doing one of the above options,
> however.

6) Any others I can't think of?
>

Slight variation, call it option 6:

1) Identify the most impacted (coupled) project affected by these changes.
2) Fix it in order to provide folks with a recipe for how to address the
breakages.
3) Use the patch and make it needed-by the neutron changes.
4) Evangelize patch 2 one more time on the ML.
5) We'll bring this up at the team meeting, for another form or record.
6) Wait another few days for projects to catch up.
7) Merge the patch in neutron.
8) We all move on.


>
>
> [1] https://review.openstack.org/#/c/343045/
> [2] http://codesearch.openstack.org/?q=from%20neutron.agent.common%20im
> port%20config&i=nope&files=&repos=
>
> [3] https://review.openstack.org/#/c/340228/
> [4] http://codesearch.openstack.org/?q=neutron.plugins.ml2%20import%20c
> onfig&i=nope&files=&repos=
>
> [5] https://review.openstack.org/#/c/347867/
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161029/661cf95e/attachment.html>