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. -Ben On 12/03/2014 10:47 PM, Steve Kowalik wrote: > Hi all, > > I'm becoming increasingly concerned about all of the code paths > in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use > nova-baremetal rather than Ironic. We do not check nova-bm support in > CI, haven't for at least a month, and I'm concerned that parts of it > may be slowly bit-rotting. > > I think our documentation is fairly clear that nova-baremetal is > deprecated and Ironic is the way forward, and I know it flies in the > face of backwards-compatibility, but do we want to bite the bullet and > remove nova-bm support? > > Cheers, > _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev