t;openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] PTG Summary
Hi Tim,
Thanks for the information.
I personally don't see problems with cleaning running weeks, when needed. What
I'd avoid is replicating the same cleaning machinery but w
enstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] PTG Summary
Hi Tim,
Thanks for the information.
I personally don't see problems with cleaning running weeks, when needed.
What
I'd avoid is replicating the same cleaning machin
ck Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [ironic] PTG Summary
...
Cleaning - Burn-in
As part of discussing cleaning changes, we discussed supporting a
"burn-in" mode where hardware
Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [ironic] PTG Summary
...
Cleaning - Burn-in
As part of discussing cleaning changes, we discussed supporting a
"burn-in" mode where hardware could be left to r
The Ironic PTG Summary - The blur(b) from the East
In an effort to provide visibility and awareness of all the things
related to Ironic, I've typed up a summary below. I've tried to keep
this fairly generalized with enough context and convey action items or
the instances of consensus where
