openstack team mailing list archive

[Gabe Westmaas <gabe.westmaas@xxxxxxxxxxxxx>]

Ah, that's right. It seems that from the users' perspective it's just a delete and we should always take the delete action, regardless of whether is soft or hard delete.  In both cases it stops using resources for the customer and it's still the responsibility of the maintainer of that installation to decide whether they can handle the extra storage, as they have to already.  Just to restate what I mean: I think a delete should always be allowed no matter the current task state, even if its configured for soft deletes, so that the experience is the same no matter how the cloud is configured.

Yes, it definitely is exposed via an extension and it made me nervous to expose to anyone except admins until we move all our task states over to this more well thought out proposal.

Thanks,
Gabe

> -----Original Message-----
> From: Yun Mao [mailto:yunmao@xxxxxxxxx]
> Sent: Friday, May 18, 2012 2:33 PM
> To: Gabe Westmaas
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] nova state machine simplification and clarification
> 
> 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@xxxxxxxxxxxxx> 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@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/1nlKmYld3xxpTv6Xx0Iky6L46smbE
> qg7-S
> >>>WPu_
> >>>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
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack Post to     :
> > openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> > https://launchpad.net/~openstack More help   :
> > https://help.launchpad.net/ListHelp