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> To: "openstack-qa-t...@lists.launchpad.net" <openstack-qa-t...@lists.launchpad.net>,"openstack@lists.launchpad.net" <openstack@lists.launchpad.net> CC: Re: [Openstack-qa-team] wait_for_server_status and Compute API 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-qa-team Post to : openstack-qa-t...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp