As many of you have probably heard, the Kubernetes community has been working to develop an integration between Kubernetes and the Open Service Broker API. Over the last 8 months, I’ve had the privilege of leading Red Hat’s participation in two main efforts. Namely the Service Catalog SIG (Special Interest Group) and Kubernetes Service Catalog as well as our engineering efforts within Red Hat to integrate the Service Catalog into OpenShift.
As part of that effort, myself and others in the Kubernetes community have been working in the Open Service Broker API working group to help evolve the API. I’m pleased to be able to announce Open Service Broker API version 2.12 (OSB 2.12) was released on 30-June-2017, the first release of the API developed by the new working group as well as the first release which is independent from the Cloud Foundry platform.
Platform Profile
As part of decoupling the Open Service Broker API from Cloud Foundry, OSB 2.12 includes a new concept of “platform profile.” In prior versions, the API only allowed platforms to send Cloud Foundry-specific coordinates. The profile feature allows any platform integrating with the OSB API to send organizational information about the party requesting that a new instance of a service be provisioned. This is a significant step toward enabling integrations between new platforms and the Open Service Broker API, because a platform can send its own coordinate system.
The Kubernetes Service Catalog already leverages the profile feature and sends the namespace of the service instance in this field. This is useful for implementing brokers that provision services in a self-service manner into the requesting namespace, such as the OpenShift template broker.
Clarification
OSB 2.12 also significantly clarifies the API semantics by using the RFC2119 specification keywords (“MUST”, “SHOULD”, etc). Additions were also made to provide significant detail about how certain corner-cases must be handled by both service brokers implementing the API and the platforms integrating with the API. This is tremendously valuable for newcomers to the ecosystem who may be implementing their first brokers or implementing a new integration with the API in their platform.
Both of these aspects of OSB 2.12 are critical to enabling our work in the Kubernetes Service Catalog and crucial to the integrations we will ship in OpenShift 3.6. On a more personal level, it’s been a great experience to work with new colleagues in the API working group. I’ve learned a ton about other platforms and the interesting projects people are developing around this API.
The Future
We have exciting things planned for future releases of the OSB API, such as:
- Parameter schemas that will allow platforms to generate rich user interfaces for provisioning and binding to services
- Asynchronous binding and unbinding
- A new Alpha API that will allow us to incubate new features over multiple releases
You can also expect to see many new service offerings in the OpenShift service catalog in future releases, including the AWS services announced at the 2017 Red Hat Summit. Stay tuned!
Categories
