Re: Droplets and Stacks


Guillaume Berche
 

Thanks Dieu for your response and for considering these use-cases!

When updating a system buildpack, only the "updated_at" field changes and
no other versionning info is available. I therefore understand that the
"updated_at" field plays the role of the "sequence number" for updates and
the suggestion for an explicit sequence number integer is not currently
considered. While the updated_at field is generic to all CC entities, and
makes it appealing for filtering, I feel that dates are heavier and more
error prone for querying than integer sequence numbers.

Besides, as buildpacks updates have security implications, would'nt it make
sense to expose "buildpack events" when they are created/updated/deleted
including the regular actor, actee information (just like other system-wide
entities such as service brokers or service plans) ?

Last, would'nt it make sense to have the buildpack staging life cycle to
invoke the buildpack "detect" script and record its output even when the -b
option is specified in "cf push" command ? This way the detailed buildpack
internal versionning information returned in STDOUT would be available and
displayed with "cf app" command regardless of whether -b option was used to
constraint use of specific buildpack.

ps: Dieu, Mike, I'm not sure whether buildpack life cycle features now fall
into the CAPI team or the buildpacks team (which tracker should I watch
stories related to this discussion ?).

Thanks again,

Guillaume.


Initial buildpack uploading:
$ cf create-buildpack gbe-static-bp-test ./binary-bp1.zip 20
$ Cf_TRACE=true cf buildpacks
[...]
{
"metadata": {
"guid": "0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"url": "/v2/buildpacks/0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"created_at": "2015-10-27T17:46:49Z",
"updated_at": "2015-10-27T17:46:50Z"
},
"entity": {
"name": "gbe-static-bp-test",
"position": 13,
"enabled": true,
"locked": false,
"filename": "binary-bp1.zip"
}
}

Buildpack update:

$ cf update-buildpack gbe-static-bp-test -p ./binary-bp2.zip -i 20
$ Cf_TRACE=true cf buildpacks
[...]

{
"metadata": {
"guid": "0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"url": "/v2/buildpacks/0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"created_at": "2015-10-27T17:46:49Z",
"updated_at": "2015-10-27T17:48:28Z"
},
"entity": {
"name": "gbe-static-bp-test",
"position": 13,
"enabled": true,
"locked": false,
"filename": "binary-bp2.zip"
}
}

On Tue, Oct 27, 2015 at 10:13 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Guillaume,

We could consider exposing on a droplet [1] the additional metadata that
you've mentioned, such as the buildpack guid for a system buildpack or the
git sha given a buildpack url.

I think it would make sense to consider adding an additional filter to
/v3/droplets to be able to query by creation date. Similarly, allowing
filters based on buildpack information sounds useful as well.

-Dieu



[1]
http://apidocs.cloudfoundry.org/222/droplets_(experimental)/get_a_droplet.html
[2]
http://apidocs.cloudfoundry.org/222/droplets_(experimental)/list_all_droplets.html


On Sun, Oct 25, 2015 at 2:40 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Mike for the additional details. Long due PR on buildpacks-docs at
[1]

Dieu, can you please comment on the suggestion above for more fine
grained buildpack versionning support ?

Thanks,

Guillaume.

[1] https://github.com/cloudfoundry/docs-buildpacks/pull/39

On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:





The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.

{
"metadata": {
"guid": "e000b78c-c898-419e-843c-2fd64175527e",
"url": "/v2/buildpacks/e000b78c-c898-419e-843c-2fd64175527e",
"created_at": "2014-04-08T22:05:34Z",
"updated_at": "2015-07-08T23:26:42Z"
},
"entity": {
"name": "java_buildpack",
"position": 3,
"enabled": true,
"locked": false,
"filename": "java-buildpack-v3.1.zip"
}
}

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

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.
I'll let Dieu respond to these suggestions, as she's the CAPI PM.

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.