Open Stack

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.