Open Stack

I agree, this looks much more clear compared to where we are now.

I'd like to understand the difference between a soft and hard delete.
Does an API user have to specify that in some way?  I definitely agree
that you should be able to delete in any state, I would rather it not be a
requirement that the user interact differently when they want to delete a
server that has a task state already set.

Gabe

What exactly is a hard delete from the standpoint of a customer?  Is this
just a delete

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