Plans should have control over whether they are bindable

[johnmcteague]

Currently only the service can be flagged as bindable. We would like plans to also be able to control whether they are bindable.

Our use case is this: we have a bespoke DBaaS offering in our marketplace with 2 plans. One is a dedicated database server, but this in itself is not bindable (what schema would an app bind to?), the other is a schema on that DB.

We want the schema to be the only bindable plan. The schema is in effect the bindable resource. We can then place multiple schemas on a database server per Org/space.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/115985379.

[SocalNick]

Hi John,

These sound like two different services, one that is unbindable and provides a dedicated DB and one that is bindable and provides schemas. I'm not sure what you gain by offering these as plans on the same service? Maybe some examples of how a user provisions the dedicated DB and schemas would help illustrate the problem.

Thanks,

Nick

[johnmcteague]

We present a DBaaS as a single marketplace entry. To us, it is more logical than having a Database-Server-aaS, which given the large number of schemas that may exist, cannot be directly bound, and a schema as a service.

The UX is something like

cf cs mariadb server mydbserver -c '{"volumeSize":"200","flavor":"large"} // i get a server using our large flavor with a 200GB data voume
cf cs mariadb schema myschema -c {"db":"mydbserver","name":"SOME_SCHEMA"} // a new schema is created in the server represented by service instance mydbserver
cf bs myapp myschema

In development, teams want to reduce costs, creating multiple schemas on the same shared DB server. Binding the schema to an app makes sense, we generate creds for that one schema (much like how the p-mysql service works). Binding the server itself would not make sense. WHat permissions would the user get?

We can deny binding simply by throwing an error from the broker, but this is not clean. We should declare to the platform that you cannot bind to it.

[shalako]

Hi @johnmcteague

What value does the create server step provide on its own? Do you enable developers to gain credentials to this server and manually provision schemas? Instead, couldn't you give the developer a schema on an existing shared server without provisioning the server? If they know it is a shared server, what value is it to specify the server? This could be opaque. If you want to offer a dedicated server, couldn't you offer a plan that provisions a schema on a dedicated server? Both of these plans would be bindable.

What is the difference in UX between CC validating the plan of an unbindable service and a broker validating an unbindable plan of a bindable service? Seems like the only difference is a call to the broker, and this is opaque to the developer.

Thank you

[johnmcteague]

We provide our dedicated DB in parallel with the existing p-mysql service. For devs who just want a DB schema to write code against, that is for them.

Our dedicated service gives our customers a database server with isolated CPU, mem and storage for their needs. We can offer 100's of GB storage which we cannot do at scale on the shared service. They can add 1..n schemas via a second plan on that and have each app bind to a schema. To us, having server and plans be different plans seems more logical than different services altogether.

The UX experience is that UI's or CLI tools would be able to to present to the user appropriate UX around this by examining the metadata of the service. UX modelled around metadata seems preferable that UX modelled around catching exceptions.

[SocalNick]

Fixed in https://github.com/cloudfoundry/capi-release/releases/tag/1.12.0