Re: Do your service brokers leverage the Org and Space fields in the broker API?

Dubois, Jan <jan.dubois@...>

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 or passed in env variables and even should not be easily accessible to admins either (ssh is disabled in the prod spaces).

Therefore we would favor keeping these values around in an optional, platform-specific mapping as well.


From: Mike Youngstrom <youngm(a)>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)>
Date: Thursday, November 3, 2016 at 1:17
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)>
Subject: [cf-dev] Re: Do your service brokers leverage the Org and Space fields in the broker API?

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 spaces. When a service is provisioned we lookup the billing code for a space or org and pass that along to the third party system we are provisioning the service on.

We could probably rework how this system functions but it would take some effort and would probably require our thirdparties to change their provisioning request process to allow us to either update the billing token outside of the provision request or impact our users by making them provide a billing code as a service parameter in their provision request. Nothing insurmountable but would be annoying.

I'm assuming the service guid isn't queryable against the CC until a provision request is successful?

Perhaps these fields can be moved to a platform specific map of values in the request? This would at least make it more obvious to broker developers that if a broker needs to use these fields the broker may not work on other platforms?


On Thu, Nov 3, 2016 at 12:23 PM, Shannon Coen <scoen(a)<mailto:scoen(a)>> wrote:
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 from other platform marketplaces will make implementation of the broker API more compelling for service providers, as it would enable multiple sales channels, growing the ecosystem of services available to CF operators.

The organization_guid and space_guid fields are sent to brokers with the create and update operations. Please let me know if you are aware of service brokers that leverage these fields, and for what purpose.

Thank you!

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Join { to automatically receive all group messages.