openstack team mailing list archive

[Yun Mao <yunmao@xxxxxxxxx>]

Hi Mark,

I haven't looked at resize related API calls very closely. But what
you are saying makes sense. revert_resize() should be able to preempt
an existing resize() call, which might get stuck. I'm not clear how
the leftovers will be garbage collected yet.

Yun

On Fri, May 18, 2012 at 10:20 AM, Mark Washenberger
<mark.washenberger@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp