Support MaintenanceInfo refresh (e.g. triggered by broker-side maintenance)

[gberche-orange]

What is the problem?

As a service consumer (a.k.a developer):

• In order to trigger automatic maintenance upgrade of a service instance outside business hours
• I need to be able to specify a scheduled maintenance window for my service
• And that the platform displays correctly only remaining candidate upgrades after a scheduled upgrade was done unattended

As a service brother author:

• In order to support both scheduled maintenance windows, and user-triggered upgrades
• I need the GET /v2/service_instances/:instance_id endpoint to return a maintenance_info field that platforms can regularly poll to discover about out-of-brands updates triggered.

Who does this affect?

This affect service broker authors, and platform authors (this would be mostly transparent to developers)

Do you have any proposed solutions?

The GET /v2/service_instances/:instance_id endpoint to return a maintenance_info field that platforms can regularly poll to discover about out-of-brands updates triggered.

Additional context

Having the platform poll the GET /v2/service_instances/:instance_id endpoint will also enable service broker upgrades to return an updated dashboard url without requiring a user to explicitly trigger a service instance upgrade.

[Samze]

Thanks raising this @gberche-orange.

To be clear, the use case you are talking about is when a service broker performs maintenance without the platform's knowledge (perhaps for an emergency security fix) and you want this behind the scenes change to be surfaced to the platform and in turn the developers?

[gberche-orange]

@Samze yes exactly.

[rsampaio]

@gberche-orange I believe this extra field can be useful and I don't see any reason to not add this information to the response of a GET request for a service instance. Would you be willing to open a PR adding these fields to the response on the spec and the openapi file?

I also remember a discussion about using Etag and Cache-control for more efficient pooling from platforms and maybe this is something we can also recommend on the spec.

[gberche-orange]

thanks @rsampaio Sure, I'll prepare a PR

[gberche-orange]

@rsampaio I've submitted PR #722 but left the discussion about Etag and Cache-control up to #529 for a distinct PR