Proposal for a broker to allow itself to be private installed across multiple spaces.

multi-space.md

Currently a private broker can only be registered once in a single private space.

See https://blog.starkandwayne.com/2015/11/18/register-your-own-service-broker-with-any-cloud-foundry/

Proposal: allow arbitrary base path which will alter the service/plan UUIDs:

cf create-service-broker dingo-pg-production user pass https://dingo-pg.starkandwayne.com/space-scoped/production

The /space-scoped/production/v2/catalog will prefix all service/plan UUIDs with production-

All incoming API calls will have production- removed on the way in.

One of the “is Dingo PG ready for other people” questions I ask most days is “Is S&W using it yet?"

[8:06]
But for us to use it on PWS we need to be able to register it

[8:07]
Sadly, the private broker implementation restricts a service broker being registered only once. FFS. https://blog.starkandwayne.com/2015/11/18/register-your-own-service-broker-with-any-cloud-foundry/

[8:07]
So, my proposal - write a proxy app that sits in front of the private broker

[8:08]
it supports the entire service broker API, and adds/removes a prefix to service-id & service-plan-id so its unique

[8:09]
GET /space/production/v2/catalog would return the normal catalog for the backend service (say dingo-pg-broker), but the service-id & plan-ids would have production- prefixed to them

[8:10]
PUT /space/production/v2/service_instance/thingy -d '{"service-id": "production-UUID",…}' would have the internal service-id stripped of its production- prefix on the way in

[8:10]
It would be stateless - no recollection of requests coming in

[8:11]
it just sees /space/:space-label/… in the route and takes the :space-label parameter