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 <[email protected]>
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 : [email protected]
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack