search

openservicebrokerapi / servicebroker

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

How to handle catalog metadata change for existing service instances #691

Closed subhankarc closed 4 years ago

subhankarc commented 5 years ago

In case of an OSBAPI compliant broker, catalog contains the service and plan details. If there is any change/update in the catalog in any of it's metadata, which is used by service to configure a specific service instance, is there a recommendation from the spec how to handle updating the existing service instances by the broker ? Should the broker trigger an update of all the service instances immediately or should it wait for an user initiated update operation ?

mattmcneeney commented 5 years ago

Hey @subhankarc

This entirely depends on the service broker implementation. Some catalog changes may not require any updates at all, and some may only affect a number of service instances. It is also possible to 'deprecate' services and plans by removing them from the catalog entirely. This won't automatically delete the relevant service instances from platforms, but no new instances will be created.

For example, with the on-demand broker SDK, when the service is updated (which could include a catalog update), the Operator has the ability to trigger an update of all affected service instances if they wish. A common problem with this though is that updates can cause downtime, which application developers may not be expecting.

Does that help?

subhankarc commented 4 years ago

Hi @mattmcneeney ,

Sorry for replying late to this. I also feel that having an ability in the broker/operator to trigger update of all affected instances would be a better approach and then the service owners can decide whether to opt for it depending on how the update would affect the service(downtime etc.)

Thanks for your reply.

Regards, Subhankar