Re: Dynamic service catalog

Matt McNeeney

Thanks Peter, that makes sense. Whilst it is the broker who is responsible
for catalog changes, admins should expect that the catalog (and therefore
marketplace entries) *may *change when they update a service broker. If
this happens automatically, then I feel we should have a clearer strategy
for how service broker authors should modify and delete existing services
and plans.

Are there any other service broker authors who have this use case? It would
be great to hear more feedback on this from others who are struggling with
the same issue.

On Mon, Nov 6, 2017 at 9:11 PM Peter Dotchev <dotchev(a)> wrote:

Hi Matt,

I would expect the behavior to be the same to the explicit broker update
as described in the documentation
With cf update-service-broker the admin does not see the catalog changes,
so he cannot approve them.
In both cases the responsibility for catalog changes is with the broker.

AFAIK service prices are not defined in the service catalog but in the
billing system, which is outside CF control.

In our case we need to support multiple service versions as they are
Each service version is deployed separately. The broker can discover all
deployed versions.
When we deploy a new service version, we expect the consumers to see it in
the catalog along with the old versions.
Asking the admin to update the broker would be an additional manual effort.

Best regards,

On Fri, Nov 3, 2017 at 2:58 PM, Matt McNeeney <mmcneeney(a)>

Hey Peter,

This is an interesting use case. The idea of CC periodically refreshing
service broker catalog's has been raised a few times before, especially
when talking about brokers that aren't deployed on CF, but are managed
somewhere else. However, this idea has raised a number of issues in the
past, including:

- What happens to existing service instances and bindings that were
created using a plan that has now disappeared?
- What happens to existing service instances and bindings that were
created using a plan that has now changed?

This is especially important if say the pricing of a plan changes, as
there is no method for a developer to 'accept' the new plan. When an admin
explicitly updates a service broker, this is mitigated as they are asking
the platform to *use *the new catalog.

I'm interested to learn more about your broker, and why you want to offer
a separate plan for each version. And if you have any thoughts on the
above, I'd welcome those too! These has been discussed at length by the
OSBAPI working group as we are keen to put the right service/plan
deprecation strategies in place to support this kind of workflow.


On Fri, Nov 3, 2017 at 12:01 PM Peter Dotchev <dotchev(a)> wrote:

Hi folks,

We need to change the set of plans offered by some of our services
In our use-case we want to provide a separate plan for each service
version. When a new service version is deployed, we want to see a new plan
for it in the marketplace.

My understanding so far is that the service catalog exposed by a service
broker is relatively static.
AFAIK Cloud Controller fetches the catalog from the broker only during
create-service-broker or update-service-broker. Both of these require admin
Is there some other mechanism to update the service catalog in the

One neat solution could be service brokers to use standard http cache
control headers in the response to GET /v2/catalog to declare the
expiration time of the catalog.
When the marketplace is requested, CC could refetch the expired service
catalogs from the respective brokers.

Best regards,

Join { to automatically receive all group messages.