Open Stack

I've refreshed the agent config patch [1] with the needed-by/depends-on
using the example patch in Dragonflow [2].

[1] https://review.openstack.org/#/c/343045/
[2] https://review.openstack.org/#/c/391853/


On Fri, Oct 28, 2016 at 4:25 PM, Armando M. <armamig at gmail.com> wrote:

>
>
> 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=
>> <http://codesearch.openstack.org/?q=from%20neutron.agent.common%20import%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=
>> <http://codesearch.openstack.org/?q=neutron.plugins.ml2%20import%20config&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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> 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/20161117/172e9afc/attachment.html>