Open Stack

On Aug 20, 2013, at 3:27 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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?

I think the decision was to use the same method for everything, although I think I remember a recent email from Boris (whose team has took on a lot of this work), saying that they are not going to continue with the shadow table approach. So if we are finished with a) in nova during Havana, it might be good to put effort into c) for Icehouse.

Vish

> 
> Thanks,
> -jay
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev