Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Dan Prince
On Thu, 2014-12-04 at 15:47 +1100, 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?

I'd vote yes.

Given that our CI jobs all currently use Ironic I think it is safe to
move forwards and remove the old Nova BM configuration.

Dan

 
 Cheers,



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Alexis Lee
Dan Prince said on Thu, Dec 04, 2014 at 08:09:56AM -0500:
  face of backwards-compatibility, but do we want to bite the bullet and
  remove nova-bm support?

+1, FWIW.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Jay Dobies

+1, FWIW.


Alexis


+1

This is similar to the no merge.py discussion. If something isn't 
covered by CI, it's going to grow stale pretty quickly.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Chris Jones
Hi

AFAIK there are no products out there using tripleonova-bm, but maybe a quick 
post to -operators asking if this will ruin anyone's day, would be good?

Cheers,
--
Chris Jones

 On 4 Dec 2014, at 04:47, Steve Kowalik ste...@wedontsleep.org 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,
 -- 
Steve
 Oh, in case you got covered in that Repulsion Gel, here's some advice
 the lab boys gave me: [paper rustling] DO NOT get covered in the
 Repulsion Gel.
 - Cave Johnson, CEO of Aperture Science
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Ben Nemec
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Clint Byrum
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev