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.washenber...@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" <yun...@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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > > >_______________________________________________ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
