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. <arma...@gmail.com> wrote: > > > On 27 October 2016 at 22:18, Brandon Logan <brandon.lo...@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-requ...@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-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