Open Stack

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.