open-service-broker-sdk
by
openshift

Description: A starting point for creating service brokers implementing the Open Service Broker API

View on GitHub ↗

Summary Information

Updated 26 minutes ago
Added to GitGenius on June 23rd, 2023
Created on April 28th, 2017
Open Issues & Pull Requests: 0 (+0)
Number of forks: 30
Total Stargazers: 30 (+0)
Total Subscribers: 233 (+0)

Issue Activity (beta)

Open issues: 0
New in 7 days: 0
Closed in 7 days: 0
Avg open age: N/A days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • lifecycle/rotten (2)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

The Open Service Broker SDK is a skeleton project written in Go that provides a starting point for developers creating service brokers that implement the Open Service Broker API. The repository is maintained by OpenShift and serves as a foundation for building brokers designed to run inside Kubernetes clusters. Rather than requiring developers to build broker implementations from scratch, this SDK offers a pre-built structure that handles the complexities of API implementation, allowing broker authors to focus on their service-specific provisioning and binding logic.

The primary purpose of this SDK is to serve as a template that developers can fork and customize for their own broker implementations. The project is specifically designed to integrate with the Kubernetes Service Catalog, making it particularly valuable for organizations looking to extend Kubernetes with custom service offerings. The README explicitly states that the intended usage pattern is for broker implementers to fork the repository and fill in their own broker-specific logic and resource definitions into the provided skeleton.

The SDK is currently in pre-alpha phase, indicating it is still under active development and refinement. The project's roadmap includes taking existing broker implementations and reimplementing them using this SDK to identify pitfalls, bugs, and establish best practices for the lifecycle of SDK-based projects. This iterative approach to development suggests the maintainers are committed to improving the SDK based on real-world usage patterns.

The SDK provides three primary areas for customization. The Broker API implementation, located in the pkg/openservicebroker/operations package, handles the core logic for provision, deprovision, bind, unbind, catalog, and lastoperation requests. These functions are automatically bound to appropriate API endpoints and invoked by the Service Catalog. The provided implementation follows a specific flow where provision requests create a ServiceInstance resource, lastoperation checks resource conditions, bind operations verify ServiceInstance existence and return credentials, unbind confirms ServiceInstance presence, deprovision deletes the ServiceInstance, and catalog requests return hardcoded entries.

Broker state is managed through custom Kubernetes resources defined by the SDK itself. The ServiceInstance resource type stores the state of provision requests and is backed by etcd storage running in a local process within the broker pod. This internal resource system allows the broker to maintain state without requiring special user permissions, though real-world implementations must consider backup and restore strategies for this data.

The SDK includes a controller that watches ServiceInstance objects and enables asynchronous provision flows. When a provision request arrives, the controller creates a ServiceInstance and returns immediately, allowing the controller to handle backend resource creation asynchronously. Once provisioning completes, the controller updates the ServiceInstance condition to Ready, which the lastoperation API uses to report status to clients. The current controller implementation simply marks instances as ready upon creation and logs deletion events, but production brokers are expected to implement actual resource cleanup logic.

The repository is classified across multiple domains including APIs, Kubernetes, service catalog, infrastructure as code, platform-as-a-service, and service broker frameworks. It shares contributors with other projects including migtools/mig-ui, kuadrant/mcp-gateway, and kuadrant/kuadrant-operator, indicating active participation in the broader Kubernetes and OpenShift ecosystem. The SDK represents a significant effort to standardize and simplify service broker development within cloud-native environments.

open-service-broker-sdk
by
openshiftopenshift/open-service-broker-sdk

Repository Details

Fetching additional details & charts...