Open Stack

On Aug 20, 2013, at 3:16 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.
> 
> Do you have a list of these places?

No. I believe Joe Gordon did an initial look long ago. Off the top of my head I remember flavors and the simple-usage extension use them.

> 
>> 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.
> 
> Well, not everyone was in the summit session, for various reasons...and some of us are still catching up. :)

Understood.

Vish

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