Adding new events table index requires truncation


Jeffrey Pak
 

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


Matt Cholick
 

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


Dieu Cao <dcao@...>
 

Yes, we'd only be truncating the table backing /v2/events. This will not
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.

-Dieu

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
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