[openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd

高田唯子 yuikotakada0313 at gmail.com
Wed Apr 22 08:26:38 UTC 2015


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 <dtantsur at redhat.com>:

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/d6155c72/attachment.html>


More information about the OpenStack-dev mailing list