<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 10:52 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</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">Excerpts from David Shrewsbury's message of 2014-04-22 10:16:42 -0700:<br>


<div class="">> Hi,<br>
><br>
> I'm working on implementing rebuild() in the nova.virt.ironic driver so<br>
> that we can support the --preserve-ephemeral option. I have a design<br>
> question and would love some feedback on it.<br>
><br>
> The way to trigger a deploy is to set the provision state to ACTIVE.<br>
> However, for a rebuild, we cannot currently use this, since the API will<br>
> return an error saying that the target state and the current provision<br>
> state are the same, and return an error.<br>
><br>
> I can think of a couple of ways around this:<br>
><br>
> (1) If target and current provision state are ACTIVE, go ahead and allow<br>
> the (re)deploy.<br>
><br>
> (2) Add a new provision state that would set the instance to a sort of<br>
> temporary limbo state, expecting to be redeployed at some point by setting<br>
> target to ACTIVE (as normal).<br>
<br>
</div>I'm not familiar with Ironic's internals, but I think rebuild is a<br>
special state, since it involves a pretty violent change to the box<br>
(overwriting the disks) that is definitely not the same as being in an<br>
ACTIVE state where the user might expect it would be working.<br><br></blockquote><div><br></div><div>I see this question as referring to what should be sent to the nodes/UUID/states/provision endpoint to trigger the rebuild operation. The operation should be distinct from the operations to provision (target: active) or wipe (target: none), so I think we need a new value to represent this, akin to sending "reboot" to the nodes/UUID/states/power endpoint.<br>

</div><div><br></div><div>As far as how the API represents the state of the node during a rebuild, I would expect the node's provision_state to represent that it is being built while that is in progress, with the provision_state being "deploying", "wait call-back", and so forth, and the target_provision_state to be "active". I don't think this needs a new state, and the API can present the same series of state changes as a normal deployment would, to make it easier for the client to follow the progress.</div>

<div><br></div><div><br></div><div>-Devananda</div><div><br></div><div><br></div></div><br></div></div>