There should be a time stamp in the event itself, that would be you deleted_at time. It could be off by a few seconds but it should be accurate enough for what you (most likely) need On Wed, Mar 18, 2015 at 12:03 PM, Stefan Kulke <stefan.kulke at heg.com> wrote: > Hi, > I'm searching for a reliable way to determine the timestamp of a volume > deletion based on the volume.delete.end events. Neither the orginial > event payload nor the payload of post triggerd events by cinder audit > contain a deleted_at field. > In the first case the timestamp of the event message corresponds to the > delete date. But if I run an cinder audit the event message timestamp > does not. > During my tests I noticed that the "audit_period_beginning" and > "audit_period_ending" are identical and correspond to the delete date, > but I'm not sure if that is reliable. > Could you please explain to me what exactly does the "audit_period_beginning" > field stand for in the context of "volume.delete" events? > Thanks, > Stefan Kulke > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150318/c722505f/attachment.html>