Even with that limitation, which buildpack is supposed to create the start command? I could see instances where the "normal" buildpack start command is fine but also cases where the add on would want

We also use the org and space guids in some brokers: 1- In autosleep [1], as to opt in for space level features (as an alternative to the usual app or route level opt-in provided through

Thanks Shannon. Public pipelines displaying risk of vulnerability for online services could be feasible by asserting the version of mandatory Cf core components, including rootfs and buildpacks. I

That is indeed true. All the use cases still assume a single main application process, and therefore a single start command, and owner of $PORT. Any additional processes are meant as helpers inside

We also use these fields in a credentials broker that hands out separate credentials in test vs. production spaces. It Is a somewhat specialized use case, where credentials must not be written to disk

We used them in a bunch of insignificant places and in one significant place. Our significant use case is that we have a billing system that associates internal billing codes with organizations and

Hi, all, Quick reminder of the CAB call next Wednesday, November 9th @ 8a PDT. In addition to open QAs with CF PMs, we are also looking for suggestions of two or three cloudfoundry-community

I don't see any consideration in the document for having multiple start commands and picking who gets the default PORT.

The Open Service Broker API working group is exploring removal of "CF-isms" from the CF broker API to support adoption of the broker API by other platforms (e.g. Kubernetes). Our hope is that support

Great release Shannon! I've been waiting for relational db support before we started using the routing api. Do you consider mysql/postresql support production ready with this release or is it still

Great ideas, Guillaume. Especially public pipelines displaying smoke test results for each provider and displaying risk of vulnerability (comparison of the providers deployed version of core vs latest

Today we released routing-release v0.141.0 with support for a zero-downtime migration from etcd to mysql or postgresql as the backing store for the routing-api. We changed our data store because the

here is how you can reproduce the issue: 1. CF PUSH APP with just one instance 2. look at the routes for that app in gorouter routes you will see one IP address bind to that route 3. restage your

Thanks Dieu and Chip for explicitly asking feedback on the 2017 certification process, and leaving time for the CF community to provide such feedback. I see seldom comments in the google docs document

An addendum: if you obtain garden-runc-release tarballs from bosh.io, please update to use the "cloudfoundry" location (https://bosh.io/releases/ github.com/cloudfoundry/garden-runc-release) instead

CVE-2016-6658 Incomplete fix for Credential Vulnerability for Custom Buildpacks Severity Medium Vendor Cloud Foundry Foundation Versions Affected - cf-release versions prior to

+ Pivotal PMs/Anchors for visibility

again this is on our CF deployment broker is also ours .. and app is also ours not on PWS wrote:

Thanks for trying John .. I dont think its broker issue .. or can it be .. it may be app issue but broker is presenting right credentials .. but this is intermittent .. I was wondering is there

I can't reproduce this. After restaging, the app no longer has service instance 1's environment variables. Which service broker is this? Could this be a bug in your service broker where it's reusing