Hi Nick,
If the STARTED event would guarantee to always include buildpack name and
guid, then BUILDPACK_SET seems redundant and could be omitted. If the
droplet change in running application is possible, we would like to know
that - so the new event would be needed. And if the droplet changes in the
stopped app, the next start would simply contain new buildpack guid/name -
correct ?

Thank you,

Piotr

Piotr Przybylski / IBM Bluemix


[image: Inactive hide details for Nicholas Calugar ---03/24/2016 02:21:23
PM---Hi Matthew, Thanks for the response. When we start an ap]Nicholas
Calugar ---03/24/2016 02:21:23 PM---Hi Matthew, Thanks for the response.
When we start an app in V3, we will always know

From: Nicholas Calugar <ncalugar(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Date: 03/24/2016 02:21 PM
Subject: [cf-dev] Re: Re: CC BUILDPACK_SET App Usage Events
------------------------------




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*
<https://www.pivotaltracker.com/story/show/111166678>

On Wed, Mar 23, 2016 at 7:34 PM Matthew Sykes <*matthew.sykes(a)gmail.com*
<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* <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*
<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(a)gmail.com>