----- Original Message ----- > > > 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?
Absolutely. > On Jul 1, 2015 12:32 PM, "Doug Wiegley" < [email protected] > > wrote: > > > > > > > > On Jun 30, 2015, at 11:22 PM, Kevin Benton < [email protected] > wrote: > > Hi, > > 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): > > 1. Removed test_lib that changes config files. > https://review.openstack.org/#/c/196583/ > 2. Removed the loopingcall common util with no deprecation cycle or > announcement. https://review.openstack.org/#/c/192999/ > > 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? > > 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: > > 1. Other repos should not rely on oslo-incubated modules. > (neutron/openstack/…) > 2. Other repos should not rely on neutron’s test infrastructure. > (neutron/tests/…) > 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.) > 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. > > We’ve been regularly merging code that breaks #3 and we have plugins that use > code from #1 and #2 today. > > 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. > > Thanks, > doug > > > > > > > > > -- > Kevin Benton > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected] ?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
