Open Stack

Gabe,

There is a flag reclaim_instance_interval on API. If it's set to 0 (by
default), everything is hard_delete. Otherwise, it's soft_delete. and
will be automatically hard deleted after the configured interval.
There is also an API extension to as force_delete, which is hard
delete no matter what.

Right now I *think* task_state is already exposed via some API
(extension?). Otherwise the dashboard won't be able to see it.

Thanks,

Yun


On Fri, May 18, 2012 at 12:26 PM, Gabe Westmaas
<gabe.westmaas at rackspace.com> wrote:
> 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
>
>
> _______________________________________________
> 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