<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>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. <br>
<br>
<br>
-------- Original message --------<br>
Subject: Re: [Openstack-qa-team] wait_for_server_status and Compute API<br>
From: Jay Pipes <jaypipes@gmail.com><br>
To: "openstack-qa-team@lists.launchpad.net" <openstack-qa-team@lists.launchpad.net>,"openstack@lists.launchpad.net" <openstack@lists.launchpad.net><br>
CC: Re: [Openstack-qa-team] wait_for_server_status and Compute API<br>
<br>
<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 06/18/2012 12:01 PM, David Kranz wrote:<br>
> There are a few tempest tests, and many in the old kong suite that is<br>
> still there, that wait for a server status that is something other than<br>
> ACTIVE or VERIFY_RESIZE. These other states, such as BUILD or REBOOT,<br>
> are transient so I don't understand why it is correct for code to poll<br>
> for those states. Am I missing something or do those tests have race<br>
> condition bugs?<br>
<br>
No, you are correct, and I have made some comments in recent code <br>
reviews to that effect.<br>
<br>
Here are all the task states:<br>
<br>
<a href="https://github.com/openstack/nova/blob/master/nova/compute/task_states.py">https://github.com/openstack/nova/blob/master/nova/compute/task_states.py</a><br>
<br>
Out of all those task states, I believe the only one safe to poll in a <br>
wait loop is RESIZE_VERIFY. All the others are prone to state <br>
transitions outside the control of the user.<br>
<br>
For the VM states:<br>
<br>
<a href="https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py">https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py</a><br>
<br>
I consider the following to be non-racy, quiescent states:<br>
<br>
ACTIVE<br>
DELETED<br>
STOPPED<br>
SHUTDOFF<br>
PAUSED<br>
SUSPENDED<br>
ERROR<br>
<br>
I consider the following to be racy states that should not be tested for:<br>
<br>
MIGRATING -- Instead, the final state should be checked for...<br>
RESIZING -- Instead, the RESIZE_VERIFY and RESIZE_CONFIRM task states <br>
should be checked<br>
<br>
I have absolutely no idea what the state termination is for the <br>
following VM states:<br>
<br>
RESCUED -- is this a permanent state? Is this able to be queried for in <br>
a consistent manner before it transitions to some further state?<br>
<br>
SOFT_DELETE -- I have no clue what the purpose or queryability of this <br>
state is, but would love to know...<br>
<br>
Best,<br>
-jay<br>
<br>
-- <br>
Mailing list: <a href="https://launchpad.net/~openstack-qa-team">https://launchpad.net/~openstack-qa-team</a><br>
Post to : openstack-qa-team@lists.launchpad.net<br>
Unsubscribe : <a href="https://launchpad.net/~openstack-qa-team">https://launchpad.net/~openstack-qa-team</a><br>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</div>
</span></font>
</body>
</html>