<div dir="ltr">+1 to the idea.<div><br></div><div>However, I think we should discuss whether the rescue interface is the appropriate path. It's initial intention was to tie into Nova's rescue interface, allowing a user whose instance is non-responsive to boot into a recovery mode and access the data stored within their instance. I think there are two different use-cases here:</div>
<div><br></div><div>Case A: a user of Nova who somehow breaks their instance, and wants to boot into a "rescue" or "recovery" mode, preserving instance data. This is useful if, eg, they lost network access or broke their grub config.</div>
<div><br></div><div>Case B: an operator of the baremetal cloud whose hardware may be malfunctioning, who wishes to hide that hardware from users of Case A while they diagnose and fix the underlying problem.</div><div><br>
</div><div>As I see it, Nova's rescue API (and by extension, the same API in Ironic) is intended for A, but not for B. TripleO's use case includes both of these, and may be conflating them.</div><div><br></div><div>
I believe Case A is addressed by the planned driver.rescue interface. As for Case B, I think the solution is to use different tenants and move the node between them. This is a more complex problem -- Ironic does not model tenants, and AFAIK Nova doesn't reserve unallocated compute resources on a per-tenant basis. </div>
<div><br></div><div>That said, I think we will need a way to indicate "this bare metal node belongs to that tenant", regardless of the rescue use case.</div><div><br></div><div>-Deva</div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 5:01 AM, Lucas Alvares Gomes <span dir="ltr"><<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Mar 12, 2014 at 8:07 PM, Chris Jones <span dir="ltr"><<a href="mailto:cmsj@tenshu.net" target="_blank">cmsj@tenshu.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><div dir="ltr">Hey<div><br></div><div>I wanted to throw out an idea that came to me while I was working on diagnosing some hardware issues in the Tripleo CD rack at the sprint last week.</div><div><br></div><div>Specifically, if a particular node has been dropped from automatic scheduling by the operator, I think it would be super useful to be able to still manually schedule the node. Examples might be that someone is diagnosing a hardware issue and wants to boot an image that has all their favourite diagnostic tools in it, or they might be booting an image they use for updating firmwares, etc (frankly, just being able to boot a generic, unmodified host OS on a node can be super useful if you're trying to crash cart the machine for something hardware related).</div>
<div><br></div><div>Any thoughts? :)</div></div></blockquote><div><br></div></div></div><div>+1 I like the idea and think it's quite useful.<br><br>Drivers in Ironic already expose a rescue interface[1] (which I don't think we had put much thoughts into it yet) perhaps the PXE driver might implement something similar to what you want to do here?<br>
<br>[1] <a href="https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L60" target="_blank">https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L60</a><br></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></blockquote></div><br></div>