adomir Dopieralski [mailto:openst...@sheep.art.pl]
> Sent: 17 March 2014 10:33
> 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)
>
> On 16/03/14 06:04, Clint Byr
On 16/03/14 06:04, Clint Byrum wrote:
> 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 ha
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
ue to operator error (1A or 1B),
you need to re-create it.
Tim
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 14 March 2014 16:55
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid of so
gt;
Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft
deletion (step by step)
On Fri, 2014-03-14 at 08:37 +0100, Radomir Dopieralski wrote:
Hello,
I also think that this thread is going in the wrong direction, but I
don't think the direction Boris wants is the cor
+1 to what Jay says here. This hidden behavior moistly just causes problems
and allows hacking hidden ways to restore things.
-Mike
On Fri, Mar 14, 2014 at 9:55 AM, Jay Pipes wrote:
> On Fri, 2014-03-14 at 08:37 +0100, Radomir Dopieralski wrote:
> > Hello,
> >
> > I also think that this thread
On Fri, 2014-03-14 at 08:37 +0100, Radomir Dopieralski wrote:
> Hello,
>
> I also think that this thread is going in the wrong direction, but I
> don't think the direction Boris wants is the correct one either. Frankly
> I'm a little surprised that nobody mentioned another advantage that soft
> de
On 14/03/14 11:08, Alexei Kornienko wrote:
> On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:
[snip]
>> OpenStack is a big, distributed system of multiple databases that
>> sometimes rely on each other and cross-reference their records. It's not
>> uncommon to have some long-running operation s
On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:
Hello,
I also think that this thread is going in the wrong direction, but I
don't think the direction Boris wants is the correct one either. Frankly
I'm a little surprised that nobody mentioned another advantage that soft
delete gives us, the on
Hello,
I also think that this thread is going in the wrong direction, but I
don't think the direction Boris wants is the correct one either. Frankly
I'm a little surprised that nobody mentioned another advantage that soft
delete gives us, the one that I think it was actually used for originally.
The restore use case is for sure inconsistently implemented and used. I
think I agree with Boris that we treat it as separate and just move on with
cleaning up soft delete. I imagine most deployments don't like having most
of the rows in their table be useless and make db access slow? That being
sa
Excerpts from Tim Bell's message of 2014-03-12 11:02:25 -0700:
>
> >
> > If you want to archive images per-say, on deletion just export it to a
> > 'backup tape' (for example) and store enough of the metadata
> > on that 'tape' to re-insert it if this is really desired and then delete it
> > fr
Excerpts from Jay Pipes's message of 2014-03-12 10:58:36 -0700:
> On Wed, 2014-03-12 at 17:35 +, Tim Bell wrote:
> > And if the same mistake is done for a cinder volume or a trove database ?
>
> Snapshots and backups?
>
and bears, oh my!
+1, whether it is large data on a volume or saved sta
Hi all,
I would like to fix direction of this thread. Cause it is going in wrong
direction.
To assume:
1) Yes restoring already deleted recourses could be useful.
2) Current approach with soft deletion is broken by design and we should
get rid of them.
More about why I think that it is broken:
For some guests we use the LVM imagebackend and there are times when the
guest is deleted on accident. Humans, being what they are, don't back up
their files and don't take care of important data, so it is not uncommon to
use lvrestore and "undelete" an instance so that people can get their data.
O
On 12 March 2014 17:35, Tim Bell wrote:
> And if the same mistake is done for a cinder volume or a trove database ?
Deferred deletion for cinder has been proposed, and there have been
few objections to it... nobody has put forward code yet, but anybody
is welcome to do so.
_
>
> If you want to archive images per-say, on deletion just export it to a
> 'backup tape' (for example) and store enough of the metadata
> on that 'tape' to re-insert it if this is really desired and then delete it
> from the database (or do the export... asynchronously). The
> same could be
March 2014 17:02
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid of
> > soft deletion (step by step)
> >
> &
lopment Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft
> deletion (step by step)
>
> Understandable,
>
> Humans will be humans after all.
>
> To me if openstsck is a cloud platform then coming along w
On Wed, Mar 12, 2014, CARVER, PAUL 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
On Wed, 2014-03-12 at 11:37 +, CARVER, PAUL 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
Tim Bell [mailto:tim.b...@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
803-1656
E: pcar...@att.com
Q Instant Message
-Original Message-
From: Tim Bell [mailto:tim.b...@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
del
On 03/11/2014 11:10 PM, Jay Pipes wrote:
> On Wed, 2014-03-12 at 01:47 +, Joshua Harlow wrote:
>> The question that I don't understand is why does this process have to be
>> involve the database to begin with?
>>
>> If you want to archive images per-say, on deletion just export it to a
>> 'back
On Wed, 2014-03-12 at 01:47 +, Joshua Harlow wrote:
> The question that I don't understand is why does this process have to be
> involve the database to begin with?
>
> If you want to archive images per-say, on deletion just export it to a
> 'backup tape' (for example) and store enough of the
Tuesday, March 11, 2014 at 11:43 AM
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
][db][performance] Proposal: Get rid of soft
deletion (step by step)
On Tue, Mar 11, 2014 at 12:43 PM, Tim Bell
mailto:tim.b...@cern.ch>> wrote:
Typical cases are user error where someone accidentally deletes an item from a
tenant. The image guys have a good structure where images
On Tue, Mar 11, 2014 at 12:43 PM, Tim Bell wrote:
>
> 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
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
On Tue, Mar 11, 2014, Mike Wilson 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 arch
point for folks (Tool to delete
>> things properly suggestions and such...).
>>
>> From: Boris Pavlovic
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>
>> Date: Monday, March 10, 2014 at 1:29 PM
>> To: OpenStack Dev
Mailing List ,
> Victor Sergeyev
> Subject: [openstack-dev] [all][db][performance] Proposal: Get rid of soft
> deletion (step by step)
>
> Hi stackers,
>
> (It's proposal for Juno.)
>
> Intro:
>
> Soft deletion means that records from DB are not actually
If the deleted column is removed, how would the 'undelete' functionality be
provided ? This saves operators when user accidents occur since restoring the
whole database to a point in time affects the other tenants also.
Tim
> Hi all,
>
> >>> I've never understood why we treat the DB as a LOG
Roman Podoliaka said on Mon, Mar 10, 2014 at 03:04:06PM -0700:
> So we have a homework to do: find out what for projects use
> soft-deletes. I assume that soft-deletes are only used internally and
> aren't exposed to API users, but let's check that. At the same time
> all new projects should avoid
I see many examples in nova of where we still read rows with
read_deleted="yes". I think we need to see a plan for how to remove
all of those before we can progress this.
Michael
On Tue, Mar 11, 2014 at 9:06 AM, Johannes Erdfelt wrote:
> On Mon, Mar 10, 2014, Joshua Harlow wrote:
>> Sounds like
On Mon, Mar 10, 2014, Joshua Harlow wrote:
> Sounds like a good idea to me.
I generally think this is a good idea too.
> I've never understood why we treat the DB as a LOG (keeping deleted == 0
> records around) when we should just use a LOG (or similar system) to
> begin with instead.
>
> Does
gs
> properly suggestions and such…).
>
> From: Boris Pavlovic
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: Monday, March 10, 2014 at 1:29 PM
> To: OpenStack Development Mailing List ,
> Victor Sergeyev
> Subject: [ope
On Tue, 2014-03-11 at 01:29 +0400, Boris Pavlovic wrote:
>
> To put in a nutshell most important issues:
> 1) Extra complexity to each select query & extra column in each index
> 2) Extra column in each Unique Constraint (worse performance)
> 3) 2 Extra column in each table: (deleted, deleted_at)
;>
Subject: [openstack-dev] [all][db][performance] Proposal: Get rid of soft
deletion (step by step)
Hi stackers,
(It's proposal for Juno.)
Intro:
Soft deletion means that records from DB are not actually deleted, they are
just marked as a "deleted". To mark record as
Hi stackers,
(It's proposal for Juno.)
Intro:
Soft deletion means that records from DB are not actually deleted, they are
just marked as a "deleted". To mark record as a "deleted" we put in special
table's column "deleted" record's ID value.
Issue 1: Indexes & Queries
We have to add in every qu
40 matches
Mail list logo
