[ironic][ops] Taking ironic nodes out of production

Bogdan Dobrelya bdobreli at redhat.com
Tue May 21 08:13:08 UTC 2019


[CC'ed edge-computing at lists.openstack.org]

On 20.05.2019 18:33, Arne Wiebalck wrote:
> Dear all,
> 
> One of the discussions at the PTG in Denver raised the need for
> a mechanism to take ironic nodes out of production (a task for
> which the currently available 'maintenance' flag does not seem
> appropriate [1]).
> 
> The use case there is an unhealthy physical node in state 'active',
> i.e. associated with an instance. The request is then to enable an
> admin to mark such a node as 'faulty' or 'in quarantine' with the
> aim of not returning the node to the pool of available nodes once
> the hosted instance is deleted.
> 
> A very similar use case which came up independently is node
> retirement: it should be possible to mark nodes ('active' or not)
> as being 'up for retirement' to prepare the eventual removal from
> ironic. As in the example above, ('active') nodes marked this way
> should not become eligible for instance scheduling again, but
> automatic cleaning, for instance, should still be possible.
> 
> In an effort to cover these use cases by a more general 
> "quarantine/retirement" feature:
> 
> - are there additional use cases which could profit from such a
>    "take a node out of service" mechanism?

There are security related examples described in the Edge Security 
Challenges whitepaper [0] drafted by k8s IoT SIG [1], like in the 
chapter 2 Trusting hardware, whereby "GPS coordinate changes can be used 
to force a shutdown of an edge node". So a node may be taken out of 
service as an indicator of a particular condition of edge hardware.

[0] 
https://docs.google.com/document/d/1iSIk8ERcheehk0aRG92dfOvW5NjkdedN8F7mSUTr-r0/edit#heading=h.xf8mdv7zexgq
[1] https://github.com/kubernetes/community/tree/master/wg-iot-edge

> 
> - would these use cases put additional constraints on how the
>    feature should look like (e.g.: "should not prevent cleaning")
> 
> - are there other characteristics such a feature should have
>    (e.g.: "finding these nodes should be supported by the cli")
> 
> Let me know if you have any thoughts on this.
> 
> Cheers,
>   Arne
> 
> 
> [1] https://etherpad.openstack.org/p/DEN-train-ironic-ptg, l. 360
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the openstack-discuss mailing list