Support bindable at the plan level as well as the service about servicebroker HOT 8 CLOSED

Planned for Service Broker API 2.11.

from servicebroker.

So the use case for this is to support within the same service some plans that are bindable, and some that are not? I don't dispute that this is valid, but I wonder if you can provide an example of where this would be useful.

from servicebroker.

@pmorie Here's the use case we're working to support:

A service provider wants to enable app developers to provision databases on servers. They also want to enable some teams to share a database server for multiple databases. Rather than grant sufficient permissions to the developers to create new databases on a server, the service providers wants to enable app developers to use the same marketplace workflows to create servers and to choose which servers a database is created on.

The service broker will offer one service offering and two plans. The first plan provisions dedicated (private) servers, without a database; we'll call this plan the "server plan." These service instances are not bindable, and only some teams have access to this plan.

The second plan provisions databases on a server; we'll call this the "database plan." By default, databases will be provisioned on a system-wide shared server. However, if an app developer has access to a service instance for a dedicated server (provisioned from the "server plan"), the app developer can provide an identifier for the service instance (service instance name?) as an arbitrary parameter with the provision request for the database plan. In this way, app developers can share a dedicated server and manage lifecycle of databases on it, all using marketplace primitives.

from servicebroker.

We have a very similar use case: We have a broker that has a service plan to create database schemas. Right now these schemas are created in a database that is configured externally. It would be great if we could introduce a database plan with which you can create the database and reference its instance when creating a schema.

While it might be nice if the database plan could be flagged as "non bindable", but the other aspect of how to reference the database instance when creating the schema instance is to me even more important. Certainly, you could just pass it as a parameter in the create-service call for the schema but then the cloud controller knows nothing about the dependency between the two and would not complain if you had a bound schema instance but try to delete the database instance.

Would be great if these kind of parent-child relations between service instances could be expressed more explicitly, e.g. by extending the create-service command by an additional parameter to specify it as a "child" of another service instance.

What do you think about this?

from servicebroker.

Hello Peter,
My challenge with this is that it only supports a relationship between objects known to the same service broker. Often, service instances depend on other service instances managed by other brokers. Currently this relationship is established via the parameters field, but could be a first-class relationship known to the platform. Currently CF doesn't support something like service-to-service bindings, but occasionally this has come up in the past.

from servicebroker.

Isn't this yet another reason why such a reference should be an explicit parameter on the create-service command to enable the cloud controller to keep track of these relations? If it is only put in the parameter field, a service broker could leverage this information broker internally (which is already insufficient as explained above) but not cross-broker.

from servicebroker.

I understand the bindeable at pla level feature is mostly a hint to UIs to not accept/propose binding user requests to some service instances of specific service plans.

The current work on JSON schema could be used to support this use-case without adding specifics to the SB API

See the following bindeable prototype referencing schemas. See more background in readme

(Sorry for late feedback on this.)
If it is not too late, it might make sense to wait a bit before merging cloudfoundry/docs-services#149 into openservicebrokerapi/servicebroker

I'll try to see how the JSON schema can used to express composition of services instances among a given service broker (i.e. a expressing constraints over a series of user requests, rather than a single request)

from servicebroker.

Closing as it is in 2.11

from servicebroker.