Open Stack

Interesting, the usage of stop to do this could work since the semantics are similar enough. People could even remap delete to stop and force-delete to delete and this would be a solution as well (or as u said use a cronjob/deletion service/janitor crew that does the force-delete).

Good idea!

Sent from my really tiny device...

> On Mar 15, 2014, at 8:41 AM, "Clint Byrum" <clint at fewbar.com> wrote:
> 
> Excerpts from Joshua Harlow's message of 2014-03-13 16:16:50 -0700:
>> Seems ok to me, and likely a good start, although I'm still not very comfortable with the effects of soft_deletion (unless its done by admins only), to me it complicates scheduling (can u schedule to something that has been soft_deleted, likely not). It also creates a  pool of resources that can't be used but can't be deleted either, that sounds a little bad and wastes companies $$ and it reinforces non-cloudly concepts. It also seems very complex, especially when your start connecting more and more resources together via heat or other system (the whole graph of resources now must be soft_deleted, wasting more $$, and how does one restore the graph of resources if some of them were also hard_deleted).
> 
> I think you stay clear of scheduling if you treat it as a stopped
> resource. It is costing you to be there, even if it isn't using the CPU
> and RAM, it is a form of reservation.
> 
> The pool of unusable resources must be built into the price for
> undeletable resources. How long to keep things around is a business
> decision. I could see an evolution of the feature that includes undelete
> period in the flavor definition.
> 
> The fact that one would need to be able to undelete whole applications
> is just a missing feature. In the case of Heat, it would definitely get
> complicated if you went out of band and accidentally deleted things but
> it would be uncomplicated as long as you undeleted it before Heat tried
> to do an in-place operation like a Metadata change + waitcondition or a
> rebuild/resize.
> 
> I think though, that we already have this feature for most things in the
> form of "stop" versus "delete". The way I would implement undelete is at
> the policy level.
> 
> Deny delete to users, and provide a cron-like functionality for
> deleting. Let them decide how long they'd like to keep things around for,
> and then let the cron-like thing do the actual deleting. I believe a few
> of these cron-as-a-service things already exist.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev