Expose Service Broker attributes/labels to CF service instances

[atanas-attodorov-wq]

Currently Service Instances might want to expose Service Broker specific attributes/labels.

Currently OSBAPI specification supports this already:
https://github.com/cloudfoundry/servicebroker/blob/v2.17/spec.md#service-instance-metadata

type ProvisionedServiceSpec struct {
	IsAsync       bool
	AlreadyExists bool
	DashboardURL  string
	OperationData string
	Metadata      InstanceMetadata
}

type InstanceMetadata struct {
	Labels     map[string]any `json:"labels,omitempty"`
	Attributes map[string]any `json:"attributes,omitempty"`
}

Here is the source of the snippet: https://github.com/cloudfoundry/brokerapi/blob/main/domain/service_broker.go

On the other hand CF ignores them. Service Instance model has Labels/Annotations but they are user driven.
https://v3-apidocs.cloudfoundry.org/version/3.204.0/index.html#labels-and-selectors

Do you think that extending the model with a new property broker_metadata that holds Labels/Attributes which comes from Service Broker is usable feature? Do you thing merging Service Broker metadata with existing user-driven metadata is an option?

Please note that Service Broker Metadata is already exposed in the face of dashboard_url ,but custom attributes cannot be exposed without code changes.

[Benjamintf1]

I think exposing labels and attributes to users of cf, through a separate source of data from generalized object labels, makes sense and would be valuable for cf to represent.

[sethboyles]

@beyhan Since you often work in this space, do you have opinions on the implementation of this?

[beyhan]

Thanks for the feature request!

To my knowledge the service instance metadata was introduced in OSB API v2.17 as part of the metadata standardization effort, specifically the "Moved attributes to metadata and returns the metadata on fetch" feature.

I agree this would be valuable to support in Cloud Controller, however there are a few considerations:

Current State:

• CF Cloud Controller currently supports OSB API v2.15 (see compatibility documentation)

• CF would need to upgrade its OSB API support to v2.17 first before implementing this feature

Regarding the implementation. I think it should be exposed through a separate field rather than merged with existing metadata fields from CF. Separating the metadata will avoid backwards compatibility issues with existing Cloud Foundry deployments.
Additionally, it would allow users to distinguish between platform-managed metadata and broker-provided metadata.