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? 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
