On 08/20/2013 05:52 PM, Vishvananda Ishaya wrote:
On Aug 20, 2013, at 2:44 PM, Mike Perez <thin...@gmail.com
<mailto:thin...@gmail.com>> wrote:
On Tue, Aug 20, 2013 at 1:59 PM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
