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
I can verify that rescue is a non-race state. The transition is active to
rescue on setting rescue, and rescue to active when leaving rescue.
Original message
Subject: Re: [Openstack-qa-team] wait_for_server_status and Compute API
From: Jay Pipes jaypi...@gmail.com
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
sure, since the semantics and tenses of
the power, VM, and task states are a bit inconsistent.
Best,
-jay
Original message
Subject: Re: [Openstack-qa-team] wait_for_server_status and Compute API
From: Jay Pipes jaypi...@gmail.com
To: openstack-qa-t...@lists.launchpad.net
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
Hi David,
Yes there is a plan to change that for Folsom. vm_state will be purely
stable state and task_state will be purely for transition state. See
http://wiki.openstack.org/VMState for the new design rational of
(power_state, vm_state, task_state)
After the cleanup, vm_state will have
ACTIVE
6 matches
Mail list logo
