Multiple binding schemas per plan

[sgran]

What is the problem? Currently only one schema for binding is available per plan, with an opaque map of parameters. This makes it difficult to create opinionated binding types, for example when there are multiple levels of access available for a service.

Who does this affect? Service broker authors

Do you have any proposed solutions? Multiple binding schemas per plan, or perhaps a better name might be binding plans.

Additional context Many services have at least the concept of read vs write as access levels to the service, and many have additional levels of granularity (can write data but not update schemas, can write data for insert but not update, can create users but not admin users, etc). As part of offering a binding to these services, it makes sense to offer prescriptive plans that encapsulate the access levels to enforce consistency in the offering.

[sgran]

Thinking about this, I suppose it should be possible to offer alternative plans with a OneOf construct in the schema, but I think it makes validation harder than it needs to be, and probably makes it quite difficult for people building UIs programatically from the schema.

[Samze]

Thanks for raising this @sgran!

We are generally hesitant to add multiple bindings schemas as it brings added complexity to the spec and additional work for platforms - platforms would need to validate against the current spec defined schema and then a list of additional schemas.

I think the idea of binding plans is an interesting one, but given there is already a workable solution with OneOf and adding multiple bindings would add extra complexity to the spec, I think we would have to see more requests for this feature.

Happy to keep this issue open for discussion in v3 and for further comments.

[lelvisl]

Same problem when I want to serve different types of bindings on one service instance - https://github.com/openservicebrokerapi/servicebroker/blob/v2.17/spec.md#types-of-binding.