We are adding STAGING_STARTED and STAGING_STOPPED app usage events:
https://www.pivotaltracker.com/story/show/111168816

We've also blocked staging an app's package if the app has a package that
is staging: https://www.pivotaltracker.com/story/show/111166772


On Thu, Mar 24, 2016 at 6:59 PM Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

Can you explain how staging tasks will be recorded? We have already seen a
number of custom buildpacks that use the 15 minutes of staging time in
interesting ways that consume significant resources. This is mitigated
today by the fact that the staging only occurs when the app transitions
from stopped to started so only the staging instance can execute; during
that period the desired state of the application is `started` so it's
billable time.

While I'm happy we won't be stopping apps when a new version is pushed, I
do think providers need a way to track the additional resource consumption
of staging to avoid misuse and abuse - especially given staging tasks are
typically executed with memory and disk limits that exceed those associated
with an app instance.

Thanks.

On Thu, Mar 24, 2016 at 5:20 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi Matthew,

Thanks for the response. When we start an app in V3, we will always know
the buildpack because we are starting the app's current droplet. The
droplet was staged with a particular buildpack, so we can record the
buildpack in the STARTED app usage event.

As promised, a couple follow up questions:

If we record the buildpack_guid in the STARTED event, can we omit the
BUILDPACK_SET event in V3?

Currently, a V3 app must be stopped to change the current droplet. We
have an upcoming story [1] to enable changing the droplet on a running
application. Would we want to add something like a DROPLET_CHANGED app
usage event to indicate a running app is now using a different buildpack?


Thanks,

-Nick

Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.

[1] https://www.pivotaltracker.com/story/show/111166678

On Wed, Mar 23, 2016 at 7:34 PM Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

The buildpack set event was implemented to enable usage based billing
for buildpack applications where the rates differed by the buildpack used
to stage the application.

When staging an application in /v2, if a buildpack is not specified, we
don't know which buildpack will stage the application until after the
detect phase of staging has occurred. That means at the time the usage
event was captured for the transition to start, the buildpack was
unavailable.

The buildpack set event makes that information available to billing
systems after staging completes.

On Tue, Mar 22, 2016 at 8:03 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

We are continuing work on the Cloud Controller V3 API and had a
question about a particular App Usage Event we write as part of V2, the
BUILDPACK_SET event. The test[1] around this indicates that we write the
app usage event when staging completes and the app is still started. In V2,
apps, packages, and droplets are very tightly coupled, so writing this
event here makes sense.

In V3, apps, packages, and droplets are first class resources and we
don't stage apps, we stage packages to create droplets. Furthermore,
staging with a particular buildpack does not affect the app until the
droplet is assigned to the app as the current droplet and the current
droplet can be changed to any valid droplet for the app. Staging completion
and the app being started no longer seem to correlate to the buildpack
being "set".

With the above differences, we are hoping to understand the use-case
around the BUILDPACK_SET event so we can correctly preserve the desired
behavior for V3. I'll likely have follow up questions, but the first thing
I'd like to know is what BUILDPACK_SET indicates to downstream billing
engines.

Thanks,

-Nick

Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.

[1]
https://github.com/cloudfoundry/cloud_controller_ng/blob/45b311f18d8ad1184dcb647081b19eca6f1eaf83/spec/unit/models/runtime/app_spec.rb#L1345-L1369

--
Matthew Sykes
matthew.sykes(a)gmail.com

--
Matthew Sykes
matthew.sykes(a)gmail.com