Adding new events table index requires truncation
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?
Raina and Jeff
CF CAPI Team
From the discussion on the story, it looks like this won't affect anytoggle quoted messageShow quoted text
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
On Mon, Sep 21, 2015 at 10:44 AM, Jeffrey Pak <jeffrey.pak(a)emc.com> wrote:
Dieu Cao <dcao@...>
Yes, we'd only be truncating the table backing /v2/events. This will nottoggle quoted messageShow quoted text
affect the tables backing /v2/app_usage_events or /v2/service_usage_events
and thus should not affect billing.
I'll clarify in the story description.
On Mon, Sep 21, 2015 at 8:00 PM, Matt Cholick <cholick(a)gmail.com> wrote:
From the discussion on the story, it looks like this won't affect any