search

openservicebrokerapi / servicebroker

Open Service Broker API Specification
https://openservicebrokerapi.org/
Apache License 2.0
1.19k stars 434 forks source link

Clarification: can service and plan names be updated? #187

Closed pmorie closed 6 years ago

pmorie commented 7 years ago

The spec says explicitly that the ID of services and plans should never change. This seems to imply that the names of these entities can change, but this is not explicitly stated in the spec, that I can find: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#catalog-management

If names are mutable, we should call it out explicitly (I'm happy to make the PR for it).

duglin commented 7 years ago

CF has this doc: https://docs.cloudfoundry.org/services/managing-service-brokers.html

Seems to me we should include a variant of this in the spec. In particular the "Catalog Validation Behaviors" table where it says:

A service or plan in the marketplace database are found with a unique_id that matches the broker catalog’s ID.

results in:

The marketplace must update the records to match the broker’s catalog.

duglin commented 7 years ago

Opened issue: https://github.com/openservicebrokerapi/servicebroker/issues/189 for my comment

bgrant0607 commented 7 years ago

It is hostile to users to change names of services. It would put them at risk of bait-and-switch, and would be an obstacle to portability, automation, and declarative configuration.

I recommend declaring them to be immutable.

pmorie commented 7 years ago

I also would strongly prefer for service names and plan names to be immutable.

mattmcneeney commented 6 years ago

@duglin I seem to remember adding clarity around this but can't find it in the spec. Am I mistaken?

duglin commented 6 years ago

I think we tried to deal with it with this text:

When determining what, if anything, has changed on a Service Broker, the Platform MUST use the id of the resources (services or plans) as the only immutable property and MUST use that to locate the same resource as was returned from a previous query. Likewise, a Service Broker MUST NOT change the id of a resource across queries, otherwise a Platform will treat it as a different resource.

When a Platform receives different id values for the same type of resource, even if all of the other metadata in those resources are the exact same, it MUST treat them as separate instances of that resource.

So I think we can close this one now. Closing...