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).
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. +1 from me for doing in similar lines - allow inband inspection to be aborted if discoverd is waiting for a callback from the node. This should cover a big chunk of time in a real bare metal. On Tue, Apr 21, 2015 at 5:12 PM, Dmitry Tantsur <[email protected]> wrote: > Hi folks. > > 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 > https://blueprints.launchpad.net/ironic-discoverd/+spec/abort-introspection > to track it. > > 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. > > 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? > > 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. > > 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. > > What do you think? > > Cheers, > Dmitry > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
