<p dir="ltr">I think we need to revisit the test infrastructure requirement. We have a lot of logic to setup and test plugins/drivers and making each repo duplicate all of that is a pretty big waste of effort. Maybe some base stuff should go in neutron lib? <br>
</p>
<div class="gmail_quote">On Jul 1, 2015 12:32 PM, "Doug Wiegley" <<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 30, 2015, at 11:22 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Hi,<div><br></div><div>We have had at least two breaking changes merge this week for out-of-tree drivers/plugins. These are just the two I noticed that broke the Big Switch CI (the one I keep an eye on since I had set it up):</div><div><br></div><div>1. Removed test_lib that changes config files. <a href="https://review.openstack.org/#/c/196583/" target="_blank">https://review.openstack.org/#/c/196583/</a><br clear="all"></div><div>2. Removed the loopingcall common util with no deprecation cycle or announcement. <a href="https://review.openstack.org/#/c/192999/" target="_blank">https://review.openstack.org/#/c/192999/</a><br></div><div><div><br></div><div>I proposed a revert for 1 that merged, but I don't particularly want to keep fighting this. What is our current policy on this? Just change whatever we want and tell plugin maintainers this is just the way things work?</div></div></div></div></blockquote><div><br></div><div>So, this is a big hairy bit of suck right now.  We expected some of this fallout with the services split and plugin decomp (in fact, we counted on it to move this ball forward), and we had adopted these guideilnes:</div><div><br></div><div>1. Other repos should not rely on oslo-incubated modules.  (neutron/openstack/…)</div><div>2. Other repos should not rely on neutron’s test infrastructure.  (neutron/tests/…)</div><div>3. For changes in any other area, they should be additive, or have a backwards compatibility shim or a big warning notice (the last being the suckiest answer.)</div><div>4. When we start getting “stable” interfaces in neutron/lib/…, which has the proviso of NO breaking changes without a shim or deprecation cycle, we get rid of restriction #3.</div><div><br></div><div>We’ve been regularly merging code that breaks #3 and we have plugins that use code from #1 and #2 today.</div><div><br></div><div>IMO, the core review team needs to be aware that neutron is now a library, and refactors and gratuitous cleanups have a pretty hefty cost. Especially in Liberty, be careful.</div><div><br></div><div>Thanks,</div><div>doug</div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div>-- <br><div><div>Kevin Benton</div></div>
</div></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div><br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>