openstack team mailing list archive

[David Kranz <david.kranz@xxxxxxxxxx>]

Thanks, Yun. The problem is that the API calls give you status which is 
neither task state nor vm state. I think these are the stable states:

ACTIVE, VERIFY_RESIZE, STOPPED, SHUTOFF, PAUSED, SUSPENDED, RESCUE, ERROR, DELETED

Does that seem right to you, and is there a plan to change that set for Folsom?

 -David




On 6/18/2012 12:51 PM, Yun Mao wrote:
> Hi Jay et al,
>
> there is a patch in review here to overhaul the state machine:
>
> https://review.openstack.org/#/c/8254/
>
> All transient state in vm state will be moved to task state. Stable
> state in task state (RESIZE_VERIFY) will be moved to vm state. There
> is also a state transition diagram in dot format.
>
> Comments welcome. Thanks,
>
> All
>
> On Mon, Jun 18, 2012 at 12:26 PM, Jay Pipes<jaypipes@xxxxxxxxx>  wrote:
> > On 06/18/2012 12:01 PM, David Kranz wrote:
> > > There are a few tempest tests, and many in the old kong suite that is
> > > still there, that wait for a server status that is something other than
> > > ACTIVE or VERIFY_RESIZE. These other states, such as BUILD or REBOOT,
> > > are transient so I don't understand why it is correct for code to poll
> > > for those states. Am I missing something or do those tests have race
> > > condition bugs?
> >
> > No, you are correct, and I have made some comments in recent code reviews to
> > that effect.
> >
> > Here are all the task states:
> >
> > https://github.com/openstack/nova/blob/master/nova/compute/task_states.py
> >
> > Out of all those task states, I believe the only one safe to poll in a wait
> > loop is RESIZE_VERIFY. All the others are prone to state transitions outside
> > the control of the user.
> >
> > For the VM states:
> >
> > https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py
> >
> > I consider the following to be non-racy, quiescent states:
> >
> > ACTIVE
> > DELETED
> > STOPPED
> > SHUTDOFF
> > PAUSED
> > SUSPENDED
> > ERROR
> >
> > I consider the following to be racy states that should not be tested for:
> >
> > MIGRATING -- Instead, the final state should be checked for...
> > RESIZING -- Instead, the RESIZE_VERIFY and RESIZE_CONFIRM task states should
> > be checked
> >
> > I have absolutely no idea what the state termination is for the following VM
> > states:
> >
> > RESCUED -- is this a permanent state? Is this able to be queried for in a
> > consistent manner before it transitions to some further state?
> >
> > SOFT_DELETE -- I have no clue what the purpose or queryability of this state
> > is, but would love to know...
> >
> > Best,
> > -jay
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp