Service Instance update question

[bparees]

I understand the spec offers service plan updates (https://github.com/openservicebrokerapi/servicebroker/blob/master/_spec.md#updating_service_instance) but I'm concerned with a scenario where the service instance itself has changed.

Consider a case where a service provider offers a service which is "single tenant provisioned postgresql" and at the time a user provisions an instance of that service, they get their own postgresql v9.4 server stood up.

Later, the service provider decides that they are going to offer postgresql v9.5 instead. So users who provision from that day forward get a v9.5 server. Is there a workflow for legacy users to request their existing v9.4 instances get updated? Is the assumption that the user will have to deprovision their instance and provision a new one? Or that the service provider is responsible for handling updating provisioned instances outside the scope of a service catalog/service broker flow? Or should the v9.5 offering be registered as a new "plan"? (Is it an abuse of "plan" to use plan to handling the versioning of the catalog offering?)

@pmorie @jim-minter

[angarg12]

My understanding is that the spec leaves this as an implementation detail to be decided by each service broker.

In Fujitsu's case, any living service instance stays the same if a service is updated, and clients need to redeploy manually. I would assume that other systems apply a rolling update transparent to the user.

Maybe @pmorie and @avade may provide more details on how Kubernetes and Cloud Foundry handle this case.

[petereberlein]

We have services that model versions as service plans and allow users to upgrade their service instances to newer versions by performing a cf update-service -p [new version plan]

[avade]

Cloud Foundry doesn't do much to help in this use case. Plans can add the version of the underlying service to the metadata/description.

How they choose to expose the new version to users could be done via adding a new plan and allowing people to cf update-service -p new-plan. Additionally they could offer a service management dashboard that allows users to login and trigger an upgrade their (see compose.io or AWS RDS for an example of this UX).

I would like to see this functionality as a first class UX in the SB API. At Pivotal we are looking at this use case of triggering upgrades directly from the CF CLI and find the SB API limiting the UX.

[petereberlein]

It would help if there was a dedicated "version" field in the SB API, next to the existing "plan". (Ab)using the plan for this is an ugly workaround as service types (what plans are meant for) and versions are multiplied and lead to a large number of plans.

[avade]

The problem we found with having a simple "version" field is that the service/plan version could be different to the software version of the underlying product.

Developers are often interested in the underlying product version, but you could imagine the following scenario:

1. A developer creates a service on the small plan of MySQL.

eg. cf cs mysql small mydb

We will refer to them as the service instance owner. The service instance comprises of:

• MySQL - 5.6
• Ubuntu - 14.04.5
• Single VM - m3.medium
• Single Disk
• Single AZ
• Single Region

2. The service provider wants to change the VM type for the mysql small plan, which as it is a single node will cause downtime. This is a change that would impact things depending on the service instance, as it will involve some downtime. How do they communicate this to the service instance owner? A version change in the plan? Then application developers can opt-in to trigger the change.

Then they run cf update-service mydb -v 1.5.0

3. The same scenario applies for any other change that would impact the consumers of the service instance.

---

The other option is to have the version only represent the product version included in the service. Then manage downtime inducing changes by another mechanism.

Really we want to protect the service instance owner from:

1. Breaking changes in the service product
2. Unexpected downtime due to service providers making changes to the underlying infrastructure

[petereberlein]

I agree that you can construct scenarios where even a version field is not sufficient and you'd have to resort to encoding multiple dimensions into one version (like 1.5.0-VM2). Although I would not regard this as the standard case, a (somehow abused) version field would still be better than an abused plan which in addition to the version dimensions also encodes the service type.
So adding a version field maybe not a silver bullet but at least an incremental improvement over the current situation.

[angarg12]

I agree with @petereberlein that a version number is better than abusing plans. Also it covers the basic use case of signalling consumers that a service has changed, so they can update (manually) to get the latest version

[gberche-orange]

From the service broker perspective, what currently prevents brokers from supporting/requiring a version field as input parameter for both service-instance create and update ? I'm not sure that a standardized version OSB field would make sense for all brokers, and value that such standardized field would bring.

From the application perspective, I however believe the service instance update platforms UX (e.g. CF) would benefit from having the application be notified upon a service instance update, similar than in the service binding update (#123) the application would need to be notified.

[gberche-orange]

Completing following yesterday's conversation on this topic with @pmorie and @angarg12:

For version upgrades that require service unavailabilities, brokers can surface this to applications by requiring absence of service binding before accepting a service instance update with a change in the version input parameter, and error service instance updates with a user facing message when bindings still exist. This can be documented to humans in the broker schema, as a description associated to the version parameter.

@bparees does this clarify your question ?

[bparees]

yeah i think it gives us a path forward.

[angarg12]

If we agree then we can draft a text description for the spec.

[deniseyu]

Hi @bparees @angarg12 @petereberlein I'm just stumbling into this thread now. I'm working with a few Pivotal teams who are experiencing the same challenge: how can we give app devs granular control over service instance upgrades, and visibility over what they're upgrading to/from? What did you end up choosing as your approach?

Also does anyone have any insight re: whether version as a first-class concept ever surfaced as an OSBAPI spec change proposal?

[n3wscott]

Also does anyone have any insight re: whether version as a first-class concept ever surfaced as an OSBAPI spec change proposal?

My guess is no because that would restrict the usage of a broker to deal with versions for you. The service class could be used as a contract for an API or schema to something running. The broker can do minor and patch level updates on your behalf. If version was there then the broker would be limited to the types of helpful management actions is could do without a) breaking the agreement on what the service class means, or b) adding a lot of semver fuzzy matching logic into the spec.

[mattmcneeney]

Closing as this is now possible following the maintenance_info work!