Updating a service instance is incompatible with other parts of the spec

[luksa]

Updating a Service Instance allows users to change the plan on an existing Service Instance. This becomes problematic when the Service Instance is already bound (which is pretty much always the case at the moment of the update):

• The binding parameter schemas are specified per Plan; if the user selects a different plan while the binding already exists, and the new plan has a different parameter schema, there's no way of updating the binding parameters apart from unbinding & re-binding.
• The same goes for response schemas. What if the broker returns a different set of credentials for different plans. Updating the Service Instance provides no method for the broker to return an updated set of credentials (but this could be solved by allowing the broker to return updated credentials whenever it wants/needs to - I think I saw this proposed somewhere).
• The spec requires the plan_id to be passed to the broker during a bind request. If you change the plan afterwards, the id that was passed in originally is now incorrect. The spec could warn broker authors about this.

Yes, the broker can simply say that the plan isn't updatable when different plans have different parameter/response schemas, but I think having different sets of credentials for different plans and still allowing users to migrate between those plans is going to be an actual requirement.

If we're allowing updates to the service instance without requiring an unbind first, we're effectively saying that binding a service instance means binding a ServiceClass, instead of binding a ServiceClass/ServicePlan pair. But then, why does a bind operation need to include the plan_id?

[duglin]

I think https://github.com/openservicebrokerapi/servicebroker/issues/340 is related

[mattmcneeney]

Closing this in lieu of #340