Open Stack

On 08/20/2013 05:52 PM, Vishvananda Ishaya wrote:
>
> On Aug 20, 2013, at 2:44 PM, Mike Perez <thingee at gmail.com
> <mailto:thingee at gmail.com>> wrote:
>
>> On Tue, Aug 20, 2013 at 1:59 PM, Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at gmail.com>> wrote:
>>
>>
>>     We should take a look at look at the various entities in the
>>     various database schemata and ask the following questions:
>>
>>     1) Do we care about archival of the entity?
>>
>>     2) Do we care about audit history of changes to the entity?
>>
>>
>> For #1 and #2, really this sounds like another thing doing this along
>> with Ceilometer. I would really like to leave this in Ceilometer and
>> not have each project get more complex in having to keep track of this
>> on their own. I start having fears of discrepancy bugs of what
>> projects' audit say and what Ceilometer audit says.
>>
>> Have Ceilometer do audits, keep temporary logs for specified time, and
>> leave it up to the ops user to collect and archive the information
>> that's important to them.
>> To answer your original question, I say just get rid of the column and
>> do a hard delete. We didn't have Ceilometer then, so we no longer need
>> to keep track in each project.
>>
>> Migration path of course should be thought of for the users that need
>> this information archived if we decide to get rid of the columns.
>
> This was actually discussed during the summit session. The plan at that
> time was:
>
> a) bring back unique constraints by improving soft delete
> b) switch to archiving via shadow tables
> c) remove archiving and use ceilometer for all of the necessary parts.
>
> c) is going ot take a while. There are still quite a few places in nova,
> for example, that depend on accessing deleted records.
>
> We realized that c) was not acheivable in a single release so decided to
> do a) so we could have unique constraints until the other issues were
> solved.
>
> So ultimately I think we are debating things which we already have a
> plan for.

Also, another follow-up question: was the decision to go with the above 
steps applied for all entities in the database(s) or was there to be a 
decision for each entity instead of a one-size-fits-all plan?

Thanks,
-jay