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

Reply via email to