openstack-qa-team team mailing list archive

[Daryl Walleck <daryl.walleck@xxxxxxxxxxxxx>]

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 <jaypipes@xxxxxxxxx>
To: "openstack-qa-team@xxxxxxxxxxxxxxxxxxx" <openstack-qa-team@xxxxxxxxxxxxxxxxxxx>,"openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
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-team@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack-qa-team
More help   : https://help.launchpad.net/ListHelp