<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 18, 2014 at 12:24 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 15 March 2014 13:07, Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>> wrote:<br>


> +1 to the idea.<br>
><br>
> However, I think we should discuss whether the rescue interface is the<br>
> appropriate path. It's initial intention was to tie into Nova's rescue<br>
> interface, allowing a user whose instance is non-responsive to boot into a<br>
> recovery mode and access the data stored within their instance. I think<br>
> there are two different use-cases here:<br>
><br>
> Case A: a user of Nova who somehow breaks their instance, and wants to boot<br>
> into a "rescue" or "recovery" mode, preserving instance data. This is useful<br>
> if, eg, they lost network access or broke their grub config.<br>
><br>
> Case B: an operator of the baremetal cloud whose hardware may be<br>
> malfunctioning, who wishes to hide that hardware from users of Case A while<br>
> they diagnose and fix the underlying problem.<br>
><br>
> As I see it, Nova's rescue API (and by extension, the same API in Ironic) is<br>
> intended for A, but not for B.  TripleO's use case includes both of these,<br>
> and may be conflating them.<br>
<br>
</div>I agree.<br>
<div class=""><br>
> I believe Case A is addressed by the planned driver.rescue interface. As for<br>
> Case B, I think the solution is to use different tenants and move the node<br>
> between them. This is a more complex problem -- Ironic does not model<br>
> tenants, and AFAIK Nova doesn't reserve unallocated compute resources on a<br>
> per-tenant basis.<br>
><br>
> That said, I think we will need a way to indicate "this bare metal node<br>
> belongs to that tenant", regardless of the rescue use case.<br>
<br>
</div>I'm not sure Ironic should be involved in scheduling (and giving a<br>
node to a tenant is a scheduling problem).<br>
<br></blockquote><div><br></div><div><div>Ironic does not need to make decisions about scheduling for nodes to be associated to specific tenants. It merely needs to store the tenant_id and expose it to a (potentially new) filter scheduler that matches on it in a way that prevents users of Nova from explicitly choosing machines that "belong" to other tenants. I think the only work needed for this is a new scheduler filter, a few lines in the Nova driver to expose info to it, and for the operator to stash a tenant ID in Ironic using the existing API to update the node.properties field. I don't envision that Nova should ever change the node->tenant mapping.</div>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If I may sketch an alternative - when a node is put into maintenance<br>
mode, keep publishing it to the scheduler, but add an extra spec to it<br>
that won't match any request automatically.<br>
<br>
Then 'deploy X to a maintenance node machine' is simple nove boot with<br>
a scheduler hint to explicitly choose that machine, and all the<br>
regular machinery will take place.<br>
</blockquote><div><br></div><div>That should also work :)</div><div><br></div><div>I don't see any reason why we can't do both.</div><div><br></div><div>-Deva</div></div></div></div>