You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The parallel in names suggests they are functionally equivalent, but this inconsistency changes how brokers use the two objects.
For example, a broker may want to add a general created_at field to both resource's metadata objects, but can't for the service binding.
Or more holistically, it sends mixed messages about OSB as a prescriptive or general specification.
Who does this affect?
Broker authors and platforms.
Do you have any proposed solutions?
Replace the specific ServiceBindingMetadata fields in favor of attributes and labels, or add the two fields in addition to existing, specific ones. The latter is probably better for backwards compatibility.
What is the problem?
ServiceInstanceMetadata
is fairly general: only two opaque objects.but the
ServiceBindingMetadata
is more specific.The parallel in names suggests they are functionally equivalent, but this inconsistency changes how brokers use the two objects.
For example, a broker may want to add a general
created_at
field to both resource's metadata objects, but can't for the service binding.Or more holistically, it sends mixed messages about OSB as a prescriptive or general specification.
Who does this affect?
Broker authors and platforms.
Do you have any proposed solutions?
Replace the specific
ServiceBindingMetadata
fields in favor ofattributes
andlabels
, or add the two fields in addition to existing, specific ones. The latter is probably better for backwards compatibility.or
The text was updated successfully, but these errors were encountered: