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" <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
