Re: [openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd
Hi, Thank you for putting it up Dmitry. As I wrote into the blueprint, if there are requests to implement API aborting introspection from operators, we should introduce this feature as API, I think. But if we just want to use this feature as debug, we had better not to introduce it as API. And, instead of introducing as API, I suppose implement only client library and call it from shell script or something like "tool". Best Regards, Yuiko Takada 2015-04-21 20:42 GMT+09:00 Dmitry Tantsur : > 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd
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 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
