openstack-qa-team team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On 06/18/2012 12:49 PM, Daryl Walleck wrote:
> 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.

I don't see a RESCUE state. I see a RESCUED state. Is that what you are 
referring to here? Want to make 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 <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