On Tue, Apr 22, 2014 at 10:52 AM, Clint Byrum <cl...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev