The Open Service Broker API [1] working group have created a proposal [2]
to make the Service Broker API less CF-specific. The proposed changes will
help grow the services community by allowing service broker authors to
create and deliver services to a range of cloud-native platforms (including
Cloud Foundry, OpenShift and Kubernetes).

The key parts of the proposal are:

- Platforms can *optionally* send a new *context *parameter to service
brokers containing platform-specific information (a Cloud Foundry platform
would send the platform name, the organization GUID and the space GUID).
- The existing *required *CF-specific parameters, *organization_guid *and
*space_guid *will be marked as deprecated to be removed from the
specification in a future version.


We'd love to get some feedback from the community on this proposal.

Many thanks,
Matt

-

[1] https://www.openservicebrokerapi.org/
[2] https://github.com/openservicebrokerapi/servicebroker/issues/115

HI,

I think this change is important and need to be done, I like the new
context parameters but not sure about the `optional`, I think it's
important to which env. / platform we are talking too.


Thanks,

On Thu, Apr 20, 2017 at 7:38 PM, Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

The Open Service Broker API [1] working group have created a proposal [2]
to make the Service Broker API less CF-specific. The proposed changes will
help grow the services community by allowing service broker authors to
create and deliver services to a range of cloud-native platforms (including
Cloud Foundry, OpenShift and Kubernetes).

The key parts of the proposal are:

- Platforms can *optionally* send a new *context *parameter to service
brokers containing platform-specific information (a Cloud Foundry platform
would send the platform name, the organization GUID and the space GUID).
- The existing *required *CF-specific parameters, *organization_guid *and
*space_guid *will be marked as deprecated to be removed from the
specification in a future version.


We'd love to get some feedback from the community on this proposal.

Many thanks,
Matt

-

[1] https://www.openservicebrokerapi.org/
[2] https://github.com/openservicebrokerapi/servicebroker/issues/115

Hi Gwenn,

We agree that this change is important. However, the Open Service Broker
API Change Policy [1] specifies the following:

New fields may be added to existing request/response messages. These fields
must be optional and should be ignored by clients and servers that do not
understand them.

Service brokers that want to be accessed from multiple platforms can check
for the presence of the context parameter, and fall back to using the
existing required fields if necessary. In a future version of the spec, we
may consider making the context parameter a required field.

Many thanks,
Matt

-

[1]
https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#change-policy
​

On Fri, Apr 21, 2017 at 3:37 AM Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

HI,

I think this change is important and need to be done, I like the new
context parameters but not sure about the `optional`, I think it's
important to which env. / platform we are talking too.


Thanks,

On Thu, Apr 20, 2017 at 7:38 PM, Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

The Open Service Broker API [1] working group have created a proposal [2]
to make the Service Broker API less CF-specific. The proposed changes will
help grow the services community by allowing service broker authors to
create and deliver services to a range of cloud-native platforms (including
Cloud Foundry, OpenShift and Kubernetes).

The key parts of the proposal are:

- Platforms can *optionally* send a new *context *parameter to
service brokers containing platform-specific information (a Cloud Foundry
platform would send the platform name, the organization GUID and the space
GUID).
- The existing *required *CF-specific parameters, *organization_guid *and
*space_guid *will be marked as deprecated to be removed from the
specification in a future version.


We'd love to get some feedback from the community on this proposal.

Many thanks,
Matt

-

[1] https://www.openservicebrokerapi.org/
[2] https://github.com/openservicebrokerapi/servicebroker/issues/115