Open Stack

On Tue, Apr 22, 2014 at 10:52 AM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from David Shrewsbury's message of 2014-04-22 10:16:42 -0700:
> > Hi,
> >
> > I'm working on implementing rebuild() in the nova.virt.ironic driver so
> > that we can support the --preserve-ephemeral option. I have a design
> > question and would love some feedback on it.
> >
> > The way to trigger a deploy is to set the provision state to ACTIVE.
> > However, for a rebuild, we cannot currently use this, since the API will
> > return an error saying that the target state and the current provision
> > state are the same, and return an error.
> >
> > I can think of a couple of ways around this:
> >
> > (1) If target and current provision state are ACTIVE, go ahead and allow
> > the (re)deploy.
> >
> > (2) Add a new provision state that would set the instance to a sort of
> > temporary limbo state, expecting to be redeployed at some point by
> setting
> > target to ACTIVE (as normal).
>
> I'm not familiar with Ironic's internals, but I think rebuild is a
> special state, since it involves a pretty violent change to the box
> (overwriting the disks) that is definitely not the same as being in an
> ACTIVE state where the user might expect it would be working.
>
>
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.

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.


-Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140422/0ba0c53a/attachment.html>