Re: Droplets and Stacks
Thanks Mike for your detailed response, more comments inlinetoggle quoted messageShow quoted text
On Tue, Aug 4, 2015 at 3:52 PM, Mike Dalessio wrote:
Just to clarify, applications intentionally do NOT require restaging to be
placed onto a new rootfs; a droplet is compatible with all future versionsthanks for correcting me on that. I had in kept mind the GHOST
vulnerability into which statically linked binary in the app or buildpack
would require a restaging (cf http://pivotal.io/security/cve-2015-0235 )
but that's likely to not be that much a common case
The cli displays the 'detected_buildpack' or 'buildpack' field returned byIt's possible that we're conflating rootfs patches with buildpack patches.
the app summary endpoint [g2] such as reproduced below
$ cf app spring-startapp
Showing health and status for app spring-startapp in [...]
requested state: stopped
last uploaded: Wed Apr 29 15:14:48 UTC 2015
t#3bd15e1 open-jdk-jre=1.8.0_45 spring-auto-reconfiguration=1.7.0_RELEASE
I understand the detailed buildpack versionning info is the data returned
by the buildpack detect script [g3]. So buildpacks (such as javabuild pack)
that would provide detailed versionning info in the detect method would
help cf operators understand if some apps are running specific vulnerable
versions of the buildpack.
On an app which was targetting a specific buildpack (e.g. -b
java-buildpack), I understand the displayed detected buildpack would not
contain as much details, and mere display the buildpack name (or git url).
If you confirm, I'll try to send a PR for on docs-* repo related to  to
suggest to print out detailed versionning info for custom buildpacks
(currently suggests to display a "framework name" with "Ruby" as an
The /v2/buildpacks endpoint (used by the "cf buildpacks" command) displays
the last update date for a buildpack, e.g.
Would'nt it make sense to have the CC increment a version number for each
update so that it becomes easier to query than only relying on dates
While it's great to have buildpacks provide themselves detailed versionning
info for their code and their most important dependencies/remote artifacts,
I feel the cf platform should provide a bit more support to help identify
versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to the
buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash commit
for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above
I'm wondering whether the CAPI team working on API V3 is planning some work
in this area, and could comment the suggestions above.
However, that doesn't easily answer the question, "who's running aThanks Mike for detailing this promising work.
Have you considered an HTTP-based API for hooking into the staging process
(as an alternative to script-based hooks mentionned into [g6]) ? This would
allow such steps to be independent of the buildpacks. Apcera pluggeable
stager model might be inspiring [g7]
One could wonder how some of the extensions you mentionned (lookup against
NIST vulnerabilty db) could be run periodically against running apps
without requiring them to restage. I guess the recent "staged droplet
download" [g8] would support such use-case.