[openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)

Clint Byrum clint at fewbar.com
Sun Mar 16 05:04:44 UTC 2014

Excerpts from Tim Bell's message of 2014-03-14 13:54:32 -0700:
> I think we need to split the scenarios and focus on the end user experience with the cloud 
> .... a few come to my mind from the CERN experience (but this may not be all):
> 1. Accidental deletion of an object (including meta data)
> 2. Multi-level consistency (such as between Cell API and child instances)
> 3. Auditing
> CERN has the scenario 1 at a reasonable frequency. Ultimately, it is due to error by
> --
> A - the openstack administrators themselves
> B - the delegated project administrators
> C - users with a non-optimised scope for administrative action
> D - users who make mistakes
> It seems that we should handle these as different cases
> 3 - make sure there is a log entry (ideally off the box) for all operations
> 2 - up to the component implementers but with the aim to expire deleted entries as soon as reasonable consistency is achieved
> 1[A-D] - how can we recover from operator/project admin/user error ?
> I understand that there are differing perspectives from cloud to server consolidation but my cloud users expect that if they create a one-off virtual desktop running Windows for software testing and install a set of software, I don't tell them it was accidentally deleted due to operator error (1A or 1B), you need to re-create it.

Totally agree with all of your points.

I think you can achieve this level of protection simply by denying
interactive users the rights to delete individual things directly, and
using stop instead of delete. Then have something else (cron?) clean up
stopped instances after a safety period has been reached.

This is an interesting counter to the opposite more fluid tactic which
is to delete instances that have been up for too long, assuming that
long lived == wrong and costly.

More information about the OpenStack-dev mailing list