Open Stack

Also, with this proposal I'd be a lot more interested in exposing task
state as a part of the API eventually.  This is helpful to communicate
whether or not other actions would be allowed in certain states.  For
example, right now we don't allow other actions when a server is
snapshotting, but while the server is being snapshotted, the state is set
to ACTIVE.  With these well thought out states, I think we could more
safely expose those task states, and we would just have to be vigilant
about adding new ones to make sure they make sense to expose to end users.

Gabe

On 5/18/12 10:20 AM, "Mark Washenberger" <mark.washenberger at rackspace.com>
wrote:

>Hi Yun,
>
>This proposal looks very good to me. I am glad you included in it the
>requirement that hard deletes can take place in any vm/task/power state.
>
>I however feel that a similar requirement exists for revert resize. It
>should be possible to issue a RevertResize command for any task_state
>(assuming that a resize is happening or has recently happened and is not
>yet confirmed). The code to support this capability doesn't exist yet,
>but I want to ask you: is it compatible with your proposal to allow
>RevertResize in any task state?
>
>"Yun Mao" <yunmao at gmail.com> said:
>
>> Hi,
>> 
>> There are vm_states, task_states, and power_states for each VM. The
>> use of them is complicated. Some states are confusing, and sometimes
>> ambiguous. There also lacks a guideline to extend/add new state. This
>> proposal aims to simplify things, explain and define precisely what
>> they mean, and why we need them. A new user-friendly behavior of
>> deleting a VM is also discussed.
>> 
>> A TL;DR summary:
>> * power_state is the hypervisor state, loaded ³bottom-up² from compute
>> worker;
>> * vm_state reflects the stable state based on API calls, matching user
>> expectation, revised ³top-down² within API implementation.
>> * task_state reflects the transition state introduced by in-progress
>>API calls.
>> * ³hard² delete of a VM should always succeed no matter what.
>> * power_state and vm_state may conflict with each other, which needs
>> to be resolved case-by-case.
>> 
>> It's not a definite guide yet and is up for discussion. I'd like to
>> thank vishy and comstud for the early input. comstud: the task_state
>> is different from when you looked at it. It's a lot closer to what's
>> in the current code.
>> 
>> The full text is here and is editable by anyone like etherpad.
>> 
>> 
>>https://docs.google.com/document/d/1nlKmYld3xxpTv6Xx0Iky6L46smbEqg7-SWPu_
>>o6VJws/edit?pli=1
>> 
>> Thanks,
>> 
>> Yun
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp