<div dir="ltr">I've refreshed the agent config patch [1] with the needed-by/depends-on using the example patch in Dragonflow [2].<div><br></div><div>[1] <a href="https://review.openstack.org/#/c/343045/">https://review.openstack.org/#/c/343045/</a></div><div>[2] <a href="https://review.openstack.org/#/c/391853/">https://review.openstack.org/#/c/391853/</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 4:25 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 27 October 2016 at 22:18, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Neutrinos,<br>
I've come across an issue that I'd like to get input/opinions on.  I've<br>
been reviewing some of the centralize config options reviews and have<br>
come across a few that would cause issues with other projects that are<br>
importing these options, especially stadium projects.  High level view<br>
of the issue:<br>
<br>
[1] would cause at least 22 projects to need to be fixed based on [2]<br>
<br>
[3] would cause at least 12 projects to need to be fixed based on [4]<br>
<br>
[5] looks to affect many other projects as well (I'm being lazy and<br>
not  counting them right now)<br>
<br>
Initially, the thinking was that moving the config options around would<br>
cause some breakage with projects outside of neutron, but that would be<br>
fine because projects shouldn't really be using neutron as a library<br>
and using it to register config options.  However, with these 3<br>
patches, I definitely don't feel comfortable breaking the amount of<br>
projects these would break.  It also makes me think that maybe these<br>
options should be in neutron-lib since they're consumed so widely.<br>
Anyway, I've come up with some possible options to deal with this, but<br>
would like to hear others' opinions on this:<br>
<br>
1) Let the patches merge and break those projects as a signal that<br>
importing these shouldn't be done.  The affected projects can choose to<br>
push fixes that continue importing the neutron config options or<br>
defining their own config options.<br>
2) Deprecate the old locations for some timeframe, and then remove<br>
later.<br>
3) Texas Three-Step: change the neutron patches to keep pointers in the<br>
old locations to the new, and then push patches to the affected repos<br>
with Depends-On directives.  Once all patches merge, push up one more<br>
patch to neutron to remove the old location.<br>
4) Abandon these reviews and do nothing.<br>
5) Move these config options to neutron-lib so that they can be used by<br>
any project.  This still requires doing one of the above options,<br>
however. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
6) Any others I can't think of?<br></blockquote><div><br></div></div></div><div>Slight variation, call it option 6:</div><div><br></div><div>1) Identify the most impacted (coupled) project affected by these changes.</div><div>2) Fix it in order to provide folks with a recipe for how to address the breakages.</div><div>3) Use the patch and make it needed-by the neutron changes.</div><div>4) Evangelize patch 2 one more time on the ML.</div><div>5) We'll bring this up at the team meeting, for another form or record.</div><div>6) Wait another few days for projects to catch up.</div><div>7) Merge the patch in neutron.</div><div>8) We all move on.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/343045/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/343045/</a><br>
[2] <a href="http://codesearch.openstack.org/?q=from%20neutron.agent.common%20import%20config&i=nope&files=&repos=" rel="noreferrer" target="_blank">http://codesearch.openstack.or<wbr>g/?q=from%20neutron.agent.comm<wbr>on%20im<br>
port%20config&i=nope&files=&re<wbr>pos=</a><br>
<br>
[3] <a href="https://review.openstack.org/#/c/340228/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/340228/</a><br>
[4] <a href="http://codesearch.openstack.org/?q=neutron.plugins.ml2%20import%20config&i=nope&files=&repos=" rel="noreferrer" target="_blank">http://codesearch.openstack.or<wbr>g/?q=neutron.plugins.ml2%20imp<wbr>ort%20c<br>
onfig&i=nope&files=&repos=</a><br>
<br>
[5] <a href="https://review.openstack.org/#/c/347867/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/347867/</a><br>
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></span></div><br></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>