/v2/*/destructively_purge_all_and_reseed_started_apps - support an event ID to finish on

[drnic]

I think there is a chance that after you've downloaded /v2/app_usage_events and /v2/service_usage_events, but before you run .../destructively_purge_all_and_reseed_started_apps there will be new events. I think this could be mitigated by passing in an argument like "?last_event_id="

All events up-to-and-including this last_event_id would be deleted but not anything newer.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/86790332.

[drnic]

Discussed in https://blog.starkandwayne.com/2015/01/22/billing-your-cloud-foundry-users/

[crhino]

@drnic We have discussed this with people who had some context on this endpoint, and the verdict is that this endpoint should only be called once, if at all. The use for this endpoint was basically to initiate a new "epoch" to start billing, it is not intended to be a weekly/monthly API call.

We would recommend that you use the /v2/app_usage_events and filter with the after_guid parameter in order to get events after a certain time. As noted on the api docs, events close to the current time should not be processed since other events might still be in transaction. The idea would be to periodically grab the events starting after a specific event guid until sometime before the current time, saving the last event guid that you process. You would then be able to periodically grab a time slice of events and use that for billing.

To periodically clean the events table, the cloud_controller_clock has a periodic job that will clean up events older than a specified date. This can be configured with the app_usage_events.cutoff_age_in_days property.

[drnic]

@crhino thanks mate! I've referenced your comment in the blog now.