{"id":18637261,"url":"https://github.com/openshift/open-service-broker-sdk","last_synced_at":"2025-04-11T09:32:37.827Z","repository":{"id":57659271,"uuid":"89739052","full_name":"openshift/open-service-broker-sdk","owner":"openshift","description":"A starting point for creating service brokers implementing the Open Service Broker API","archived":false,"fork":false,"pushed_at":"2017-08-11T04:04:54.000Z","size":29668,"stargazers_count":31,"open_issues_count":0,"forks_count":33,"subscribers_count":238,"default_branch":"master","last_synced_at":"2025-03-25T12:12:09.121Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openshift.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-04-28T19:38:18.000Z","updated_at":"2022-05-21T14:57:14.000Z","dependencies_parsed_at":"2022-09-08T01:10:48.496Z","dependency_job_id":null,"html_url":"https://github.com/openshift/open-service-broker-sdk","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fopen-service-broker-sdk","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fopen-service-broker-sdk/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fopen-service-broker-sdk/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fopen-service-broker-sdk/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openshift","download_url":"https://codeload.github.com/openshift/open-service-broker-sdk/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248368318,"owners_count":21092335,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-07T05:34:40.263Z","updated_at":"2025-04-11T09:32:32.781Z","avatar_url":"https://github.com/openshift.png","language":"Go","funding_links":[],"categories":["Service Discovery \u0026 Registry"],"sub_categories":[],"readme":"# Open Service Broker SDK\n\n[![Build Status](https://travis-ci.org/openshift/open-service-broker-sdk.svg?branch=master)](https://travis-ci.org/openshift/open-service-broker-sdk)\n\nA skeleton project for creating new service brokers that implement the\n[Open Service Broker API](https://github.com/openservicebrokerapi/servicebroker).\nOur goal is eventually to make this project a full-featured SDK that handles\nthe subtleties of implementing the API and allows broker authors to focus on\nthe business logic of provisioning and binding to their services.\n\n## Purpose\n\nThis is intended as a starting point for new broker implementations that will\nrun inside a kubernetes cluster.  The intent is for broker implementers to\nfork this repository and fill in their own broker specific logic/resource\ndefinitions into the skeleton that is provided.\n\nWe are specifically most interested in brokers that will integrate with the\n[Kubernetes Service Catalog](https://github.com/kubernetes-incubator/service-catalog).\n\n## Current Status\n\nThis project is currently in the pre-alpha phase of its existence.  The\ncurrent usage pattern for this project is to fork/clone it and modify it in\norder to implement your own broker.\n\nOur next step is to take existing brokers and reimplement them using this\nproject. This will allow us to find pitfalls and bugs as well as determining\nwhat the lifecycle of a project based on this SDK should look like.\n\n## Running the example\n\n```\n$ make images\n$ # start up an openshift/kube cluster\n$ # have admin credentials\n$ cd install\n$ cd \u003ckubernetes|openshift\u003e\n$ ./install.sh\n$ cd ../../test-scripts\n$ ./provision.sh\n$ ./bind.sh\n$ ./unbind.sh\n$ ./deprovision.sh\n```\n\n## Developing a new broker\n\n### Setting up your fork\n\n1) Fork the repository\n2) Clone your fork\n3) Run `hack/fork-rename.sh \u003cyour github org name\u003e \u003cyour github repo name\u003e`\n    *  this will rename all the package imports to match your project\n\n### Customizing the repo\n\nIn writing your own Broker implementation, you will primarily be concerned with the following 3 areas:\n\n* Broker API implementation - pkg/openservicebroker/operations\n* Broker State Resources - pkg/apis/broker, pkg/registry/broker/serviceinstance\n* Provision Controller implementation - pkg/controller\n\n\n#### Broker API Implementation\n\nThe main logic of what your broker will do when `provision`/`deprovision`/`bind`/`unbind`/`catalog`/`lastoperation` requests\nare made is implemented in the `pkg/openservicebroker/operations` package.  These functions\nare automatically bound to the appropriate API endpoints by the Broker SDK and will be invoked\nby the `Service Catalog`.\n\nYou can customize this logic to implement whatever actions you want to take in response to requests from the Service Catalog.\n\nThe provided implementation executes the following flow:\n\n1) On provision, a `ServiceInstance` resource is create.  This is a Kubernetes resource that is provided by the Broker SDK\nitself and stored in a local etcd instance that will be running in the same pod as the Broker.  A controller(see next section) will\nobserve the new ServiceInstance and process it to complete the provision operation, and add the Ready condition\n\n2) On a lastoperation request, the `ServiceInstance` object conditions will be checked to see if it is Pending, Ready, or Failed.\n\n3) On bind, the broker confirms the presence of a `ServiceInstance` with a matching uuid, and if found, returns some credential\ninformation associated with the ServiceInstance.\n\n4) On unbind, the broker confirms the presence of a `ServiceInstance` with a matching uuid and based the success/failure response\non the existence of that object.\n\n5) On deprovision, the broker deletes the `ServiceInstance` object.  The controller could, but does not currently, take some\nadditional action upon receiving the deletion event.\n\n6) On a catalog request, the broker returns a valid, but hardcoded, list of catalog entries.\n\n#### Broker State Resources\n\nThe Broker SDK defines its own API group resource which is served by the API server which is part of the Broker process.\nThis API group defines one resource type, a `ServiceInstance`.  This resource is used to store the state of provision requests.\nDefining additional resources or customization to this resource are expected during usage of the SDK.  Since the Broker calls\nitself to access these resources, no special permissions should need to be granted to users to access the resources, they\ncan be considered internal only.  The resources are backed by etcd storage in a local etcd process running in a second container\nwith in the Broker SDK pod that is defined.  Real world implementations will need to take into account the backup/restore\nstrategies for this data.\n\n\n#### Controller Implementation\n\nThe Broker SDK provides a single controller which watches for `ServiceInstance` objects.  This allows it to implement an\nasynchronous provision flow in which the provision call returns immediately after defining a new `ServiceInstance` (\neffectively a service provision request).  The controller is free to implement any business logic necessary to handle\nthe request, such as creating backend resources needed by the service instance being provisioned.  Once the service\ninstance is prepared, the controller updates the `ServiceInstance` object condition to indicate it is ready.  This\ninformation is used by the `lastoperation` API when checking on the state of a provision request.\n\nOn provision, the current controller implementation simply updates the `ServiceInstance` to indicate it is ready.\nOn deletion, the controller simply logs the event but a real Broker would be expected to cleanup the provisioned resources\nhere.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenshift%2Fopen-service-broker-sdk","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenshift%2Fopen-service-broker-sdk","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenshift%2Fopen-service-broker-sdk/lists"}