In this Pull Request, we introduce a new ServiceInstanceMetadata object that allows the Broker to associate specific metadata, more specifically labels, with Service Instances. By doing that Service Instances can be labelled with information defined by the Broker. The Platform can update its view of the labels. Service Instances with specific labels may be identified by Users via the Platform, in order to perform specific actions against those instances.
As an example, let's consider a MySQL Service Offering containing multiple Service Plans. A particular Service Plan combined with a specific set of parameters used in the Provision request could produce a Service Instance eligible for a multi-source replication topology. A User might want to take advantage of this feature and connect multiple MySQL Service Instances together. However, as not all existing MySQL Service Instances support multi-source replication, the User should be able to identify and select the eligible ones. This use case can be made possible by giving the Broker the ability to associate specific labels with Service Instances during a Provision or Update request, which will be returned to the Platform. The Platform can then store and make those labels available to the User, allowing them to identify and select the specific Service Instances.
The ServiceInstanceMetadata object follows a precedent established by the existing BindingMetadata object. We propose the creation of the ServiceInstanceMetadata object at the heart of the specification as opposed to a profile given the fact Platforms such as Kubernetes and Cloud Foundry already have this concept.
Checklist:
✅ The swagger.yaml doc has been updated with any required changes
✅ The openapi.yaml doc has been updated with any required changes
What is the problem this PR solves?
In this Pull Request, we introduce a new
ServiceInstanceMetadata
object that allows the Broker to associate specificmetadata
, more specificallylabels
, with Service Instances. By doing that Service Instances can be labelled with information defined by the Broker. The Platform can update its view of thelabels
. Service Instances with specificlabels
may be identified by Users via the Platform, in order to perform specific actions against those instances.As an example, let's consider a MySQL Service Offering containing multiple Service Plans. A particular Service Plan combined with a specific set of parameters used in the Provision request could produce a Service Instance eligible for a multi-source replication topology. A User might want to take advantage of this feature and connect multiple MySQL Service Instances together. However, as not all existing MySQL Service Instances support multi-source replication, the User should be able to identify and select the eligible ones. This use case can be made possible by giving the Broker the ability to associate specific
labels
with Service Instances during a Provision or Update request, which will be returned to the Platform. The Platform can then store and make thoselabels
available to the User, allowing them to identify and select the specific Service Instances.The
ServiceInstanceMetadata
object follows a precedent established by the existing BindingMetadata object. We propose the creation of theServiceInstanceMetadata
object at the heart of the specification as opposed to a profile given the fact Platforms such as Kubernetes and Cloud Foundry already have this concept.Checklist:
@FelisiaM, @addytripathi & Diego