From the discussion on the story, it looks like this won't affect any
billing? I want to be sure as we base our billing off event data, and
missing an event could mean we'd continue to bill for applications that
were shut down (or never bill for an app). We're billing off of
/v2/app_usage_events and using the state. Is the distinction that you're
truncating the table behind /v2/events but *not* /v2/app_usage_events? It's
unclear from the story what is being truncated vs preserved, from the api
perspective.

-Matt

On Mon, Sep 21, 2015 at 10:44 AM, Jeffrey Pak <jeffrey.pak(a)emc.com> wrote:

Hi all,

The CAPI team is looking to merge in a PR to cloud_controller_ng,
https://github.com/cloudfoundry/cloud_controller_ng/pull/418, which will
update an index on the events table to include "id" as well as "timestamp".
See https://www.pivotaltracker.com/story/show/101985370 for more
information and discussion.

Older deployments with many events would experience a very slow deploy if
this migration runs as-is. To prevent this from causing failed deploys or
unintended downtime, we'd like to truncate the events table as part of the
migration.

If we do this, it'll be made clear in the release notes and will most
likely be included in v219.

Any questions or concerns?

Thanks,

Raina and Jeff
CF CAPI Team