Excerpts from Ben Nemec's message of 2014-12-04 11:12:10 -0800: > FWIW, I think the "correct" thing to do here is to get our Juno jobs up > and running and have one of them verify the nova-bm code paths for this > cycle, and then remove it next cycle. > > That said, I have no idea how close we are to actually having Juno jobs > and I agree that we have no idea if the nova-bm code actually works > anymore (although that applies to backwards compat as a whole too). > > I guess I'm inclined to just leave it though. AFAIK the nova-bm code > isn't hurting anything, and if it does happen to be working and have a > user then removing it would break them for no good reason. If it's not > working then it's not working and nobody's going to accidentally start > using it. The only real downside of leaving it is if it is working and > someone would happen to override our defaults, ignore all the > deprecation warnings, and start using it anyway. I don't see that as a > big concern. > > But I'm not super attached to nova-bm either, so just my 2 cents. >
I think this is overly cautious, but I can't think of a moderately cautious plan, so let's just land deprecation warning messages in the image builds and devtest scripts. I don't know if there's much more we can do without running the risk of yanking the rug out from some silent user out there. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
