Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
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
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

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,
Peter

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.

Matt


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

Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
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
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

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,
Peter

Hi Matt,

I would expect the behavior to be the same to the explicit broker update
as described in the documentation
<https://docs.cloudfoundry.org/services/managing-service-brokers.html#catalog-validation>
.
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
incompatible.
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,
Peter


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

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.

Matt


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

Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
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
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

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,
Peter