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

Mike Youngstrom <youngm@...>

We used them in a bunch of insignificant places and in one significant

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


On Thu, Nov 3, 2016 at 12:23 PM, Shannon Coen <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.