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.

Cheers,
-Jan

From: Mike Youngstrom <youngm(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Thursday, November 3, 2016 at 1:17
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
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?

Mike