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
