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