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
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
Hi
AFAIK there are no products out there using tripleo&nova-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 wrote:
>
> Hi all,
>
>I'm becoming increasingly concerned about all o
+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/mail
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 mail
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
