On Aug 20, 2013, at 3:16 PM, Jay Pipes <jaypi...@gmail.com> wrote: > 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. > > 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
