On Aug 20, 2013, at 2:44 PM, Mike Perez <[email protected]> wrote: > On Tue, Aug 20, 2013 at 1:59 PM, Jay Pipes <[email protected]> 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. Vish > > -Mike Perez > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
