<div dir="ltr"><div><br></div><div>In my opinion, Ironic has a (better) way for doing deploy aborts.  During a deploy in a real-world case, major chunk of time for the deploy is spent in booting up the bare metal.  The state of node during this time is wait-call-back.  It is possible today to abort the deploy when state of the node is wait-call-back (by doing set-provision-state deleted).  </div><div><br></div><div>I guess same can apply for inband inspection which requirs node to be booted up.  It should be reasonable to allow people (for debugging) to abort it during this time.  </div><div><br></div><div>+1 from me for doing in similar lines - allow inband inspection to be aborted if discoverd is waiting for a callback from the node.  </div><div><br></div><div>This should cover a big chunk of time in a real bare metal.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 5:12 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks.<br>
<br>
Recently I got several requests to implement API aborting introspection in discoverd. This is useful mostly when debugging, when you know that introspection has failed, and you want to stop it right now. I've put a blueprint <a href="https://blueprints.launchpad.net/ironic-discoverd/+spec/abort-introspection" target="_blank">https://blueprints.launchpad.net/ironic-discoverd/+spec/abort-introspection</a> to track it.<br>
<br>
Such API would cause discoverd to set error state for the node immediately and issue a power off request for it. The technical side is not a big deal.<br>
<br>
What I'm worried about is whether we want to introduce such a feature at all. Some Ironic processes (deploy, in-band cleaning) are async as well, they also may hang, and IIUC we don't have means of aborting them. Does debugging justify introducing new API?<br>
<br>
This looks somewhat similar to our discussion about breaking locks in Ironic: it might be useful, but it's an API which we'll support and which can be easily misused.<br>
<br>
But with introspection the only case where lack of this feature can't be easily worked around is when people want to recreate a node. I've been arguing for some time that recreating a node is not a good way to solve problems. In other cases one can just power off the node via Ironic API and restart the introspection again afterwards.<br>
<br>
What do you think?<br>
<br>
Cheers,<br>
Dmitry<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>