Open Stack

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