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

Joshua Harlow harlowja at yahoo-inc.com
Wed Mar 12 16:01:53 UTC 2014


Understandable,

Humans will be humans after all. 

To me if openstsck is a cloud platform then coming along with it should be best practices that come with the usage of a cloud platform (treat your instances as ephemeral, use configuration management, save your stuff in source control...). I have been preaching similar stuff at y! and getting people into the right mindset around "the cloud" is IMHO more important than making openstack fit peoples non-cloudy mindset.

Because once u teach a person to use the cloud right u don't need to have openstack compensate for them using it incorrectly.

Sent from my really tiny device...

> On Mar 12, 2014, at 4:45 AM, "CARVER, PAUL" <pc2929 at att.com> wrote:
> 
> I have personally witnessed someone (honestly, not me) select "Terminate Instance" when they meant "Reboot Instance" and that mistake is way too easy. I'm not sure if it was a brain mistake or mere slip of the mouse, but it's enough to make people really nervous in a production environment. If there's one thing you can count on about human beings, it's that they'll make mistakes sooner or later. Any system that assumes infallible human beings as a design criteria is making an invalid assumption.
> 
> -- 
> Paul Carver
> VO: 732-545-7377
> Cell: 908-803-1656
> E: pcarver at att.com
> Q Instant Message
> 
> 
> -----Original Message-----
> From: Tim Bell [mailto:Tim.Bell at cern.ch] 
> Sent: Tuesday, March 11, 2014 15:43
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)
> 
> 
> Typical cases are user error where someone accidentally deletes an item from a tenant. The image guys have a good structure where images become unavailable and are recoverable for a certain period of time. A regular periodic task cleans up deleted items after a configurable number of seconds to avoid constant database growth.
> 
> My preference would be to follow this model universally (an archive table is a nice way to do it without disturbing production).
> 
> Tim
> 
> 
>>> On Tue, Mar 11, 2014, Mike Wilson <geekinutah at gmail.com> wrote:
>>> Undeleting things is an important use case in my opinion. We do this
>>> in our environment on a regular basis. In that light I'm not sure that
>>> it would be appropriate just to log the deletion and git rid of the
>>> row. I would like to see it go to an archival table where it is easily restored.
>> 
>> I'm curious, what are you undeleting and why?
>> 
>> JE
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list