pmorie / osb-starter-pack

A quickstart for making a new Open Service Broker

OSB Starter Pack

A go quickstart for creating service brokers that implement the Open Service Broker API based on osb-broker-lib. Broker authors implement an interface that uses the same types as the go-open-service-broker-client project.

Who should use this project?

You should use this project if you're looking for a quick way to implement an Open Service Broker and start iterating on it.

Prerequisites

You'll need:

• go
• A running Kubernetes (or openshift) cluster
• The service-catalog installed in that cluster

If you're using Helm to deploy this project, you'll need to have it installed in the cluster. Make sure RBAC is correctly configured for helm.

Getting started

You can go get this repo or git clone it to start poking around right away.

The project comes ready with a minimal example service that you can easily deploy and begin iterating on.

Get the project

$ go get github.com/pmorie/osb-starter-pack/cmd/servicebroker

Or clone the repo:

$ cd $GOPATH/src && mkdir -p github.com/pmorie && cd github.com/pmorie && git clone git://github.com/pmorie/osb-starter-pack

Change into the project directory:

$ cd $GOPATH/src/github.com/pmorie/osb-starter-pack

Deploy broker using Helm

Deploy with Helm and pass custom image and tag name. Note: This also pushes the generated image with docker.

$ IMAGE=myimage TAG=latest make push deploy-helm

Deploy broker using Openshift

Deploy to OpenShift cluster by passing a custom image and tag name. Note: You must already be logged into an OpenShift cluster. This also pushes the generated image with docker.

$ IMAGE=myimage TAG=latest make push deploy-openshift

Running either of these flavors of deploy targets will build the broker binary, build the image, deploy the broker into your Kubernetes, and add a ClusterServiceBroker to the service-catalog.

Adding your business logic

To implement your broker, you fill out just a few methods and types in pkg/broker package:

• The Options type, which holds options for the broker
• The AddFlags function, which adds CLI flags for an Options
• The methods of the BusinessLogic type, which implements the broker's business logic
• The NewBusinessLogic function, which creates a BusinessLogic from the Options the program is run with

Goals of this project

• Make it extremely easy to create a new broker
• Have a batteries-included experience that gives you the good stuff right out of the box, for example:
  • Checks on who can make calls to the broker using Kubernetes subject-access-reviews
  • Easy on-ramp to instrumenting your broker with Prometheus metrics

osb-starter-pack's Issues

Change to MIT license

Currently this project uses an Apache license, but considering the whole point of this project is for people to clone and take the code and adjust it, we should have a more permissive license.

cc @pmorie @carolynvs

Basic Auth Question

This is more of a question rather than an issue, does the current osb-broker-pack implementation provide basic auth when I interact with the broker?

For example instead of doing curl http://<brokerip>:<port>/v2/catalog I would like to do curl http://user:pass@<brokerip>:<port>/v2/catalog

Thanks!

Ineffective constraint in Gopkg.toml

If you run dep ensure with the latest version of dep, it will point out that we are setting a constraint that is ignored by dep:

$ dep ensure
Warning: the following project(s) have [[constraint]] stanzas in Gopkg.toml:

  ✗  gopkg.in/yaml.v2

However, these projects are not direct dependencies of the current project:
they are not imported in any .go files, nor are they in the 'required' list in
Gopkg.toml. Dep only applies [[constraint]] rules to direct dependencies, so
these rules will have no effect.

Either import/require packages from these projects so that they become direct
dependencies, or convert each [[constraint]] to an [[override]] to enforce rules
on these projects, if they happen to be transitive dependencies,

Since dep is already properly detecting v2 of the yaml package, that entry can be safely removed.

Or if it's critical that we set that constraint, a dummy import can be added to the code to force dep to enforce the constraint by promoting it to a direct dependency.

Vendor dir should not be commited.

Since you are using the dep as a package manager, shouldn't you be grabbing those dependencies during docker build? Vendor should not be committed, we can do dep ensure or a similiar command to make sure all the deps are in sync.

User code should go in clearly designated places

It should be super clear and obvious where users should be modifying code. Ideally, there should be specific packages designated for user code. This way, if we find that people routinely need to modify code outside these packages, perhaps abstractions need to change.

issue with service_instances API calls

I'm on kube 1.10, using the 0.0.1 tag, and finding that curl calls to
the broker's "service_instance/XXXX' is not returning any results. Might be a bug or
some kind of version conflict. I'm using the latest service catalog image.

Parameterize image in makefile

It's currently hard-coded to quay.io/osb-starter-pack/servicebroker

Add ability to update service instance

issues with Bearer Token under Kuberenetes

While rebasing #92 I hit several issues:

• even with authenticate set to false, we still include the new authInfo in the broker.yaml - I think the chart needs to conditionally include this
• in my deployment, it appears the secret name is off. I believe helm created the secret we want by the name "broker-skeleton-broker-skeleton-service-token-p59vc" but the yaml is specifying {"namespace":"broker-skeleton","name":"broker-skeleton-broker-skeleton"}
• charts/servicebroker/templates/broker-service-account.yaml looks to need "apiGroup: rbac.authorization.k8s.io" under the newly added roleRef in broker-service-account.yaml

Potential interface name change from osb-broker-lib

Once this PR merges in osb-broker-lib pmorie/osb-broker-lib#21
we'll need to fix osb-starter-pack

pmorie/osb-broker-lib#14

Makefile using helm fails

The make commands fails because of docker push.
Error: Unauthorised access to docker.
This happens because the repository is to be created before pushing the image.
Please add a note in documentation or the Makefile has to be changed to include the name of the user and repository.
Ref: https://success.docker.com/article/getting-unauthorized-authentication-required-when-trying-to-push-image-to-dtr

Confused about ImagePullPolicy

After cloning the starter pack and not making any changes, I ran make helm-deploy and the broker cannot deploy because the image isn't present, and the helm command explicitly turns off image pulling (error below).

I'm not quite sure what the intended workflow was?

Originally (before trying the starter pack) I was using draft to avoid requiring a registry, and I'm mostly curious if you had another workaround, or if it's expected that I'm pushing the image somewhere before deploying. If so, the README needs to be updated to include that step.

$ kubectl describe po/broker-skeleton-broker-skeleton-5bfd8c4d5f-pvcps -n broker-skeleton
Name:           broker-skeleton-broker-skeleton-5bfd8c4d5f-pvcps
Namespace:      broker-skeleton
Node:           minibroker/192.168.99.100
Start Time:     Tue, 06 Feb 2018 08:24:00 -0600
Labels:         app=broker-skeleton-broker-skeleton
                chart=broker-skeleton-0.0.1
                heritage=Tiller
                pod-template-hash=1698470819
                release=broker-skeleton
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"broker-skeleton","name":"broker-skeleton-broker-skeleton-5bfd8c4d5f","uid":"5fb85...
Status:         Pending
IP:             172.17.0.12
Created By:     ReplicaSet/broker-skeleton-broker-skeleton-5bfd8c4d5f
Controlled By:  ReplicaSet/broker-skeleton-broker-skeleton-5bfd8c4d5f
Containers:
  service-broker-skeleton:
    Container ID:
    Image:         quay.io/osb-starter-pack/servicebroker:latest
    Image ID:
    Port:          8080/TCP
    Command:
      /opt/servicebroker/servicebroker
    Args:
      --port
      8080
      -v
      5
      -logtostderr
    State:          Waiting
      Reason:       ErrImageNeverPull
    Ready:          False
    Restart Count:  0
    Liveness:       tcp-socket :8080 delay=10s timeout=2s period=10s #success=1 #failure=3
    Readiness:      tcp-socket :8080 delay=10s timeout=2s period=10s #success=1 #failure=1
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rtfq (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  default-token-8rtfq:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-8rtfq
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     <none>
Events:
  Type     Reason                 Age               From                 Message
  ----     ------                 ----              ----                 -------
  Normal   Scheduled              32s               default-scheduler    Successfully assigned broker-skeleton-broker-skeleton-5bfd8c4d5f-pvcps to minibroker
  Normal   SuccessfulMountVolume  32s               kubelet, minibroker  MountVolume.SetUp succeeded for volume "default-token-8rtfq"
  Warning  ErrImageNeverPull      3s (x4 over 32s)  kubelet, minibroker  Container image "quay.io/osb-starter-pack/servicebroker:latest" is not present with pull policy of Never
  Warning  FailedSync             3s (x4 over 32s)  kubelet, minibroker  Error syncing pod

Extract rest and broker pkgs to a separate library

As discussed before this will make it easier for individual brokers to keep up without needing to rebase agains the osb-starter-pack.

Serve metrics over https by default

We should serve metrics over https.

• For helm, we can generate certicates in a chart
• For openshift, we can use service serving certificates

Implement API surface for LastOperation

Not done yet...

Serve everything over https by default

more generally than #73, we ought to serve everything over https by default :)

Make it easy to instrument a broker with prometheus metrics

So that you can effectively monitor brokers in production.

Provisioning example does not store the service class or plan.

This will result in provisioning an object of the same id with the same parameters, but different classes and the broker will say this is already created rather than an id collision.

Question / Suggestion: Persisting state

The starter pack broker keeps track of provisioned services in-memory and is blissfully ignorant of any previous doings when restarted. At a minimum, a persistent table to map instance IDs between the marketplace and the service provider worlds would be very useful.

Is there a best practice for keeping state and metadata of service instances in the scope of a specific broker? Would having the broker annotate the service catalog serviceinstance objects be a reasonable approach?

I've tried keeping state in a kubernetes custom resource. It's proven a convenient way to achieve persistence, but this is probably not the ideal use of CRDs and introducing another entity with it's own lifecycle is a sure way to end up with inconsistency issues, speaking from experience.

There should be user hooks for Start and Stop

To allow user to hook into process lifecycle and handle things like starting/stopping storage / writing state to disk.

Unable to find originating identity error

I get the following error when trying to use latest release of the https://github.com/pmorie/osb-broker-lib.

Warning   ClusterServiceBrokerReturnedFailure   service-catalog-controller-manager   Error provisioning ServiceInstance of ClusterServiceClass (K8S: "50e86479-4c66-4236-88fb-a1e61b4c9448" ExternalName: "redis-habitat") at ClusterServiceBroker "habitat-broker": Status: 400; ErrorMessage: <nil>; Description: unable to find originating identity; ResponseError: <nil>
Warning   DeprovisionCallFailed                 service-catalog-controller-manager   Deprovision call failed; received error response from broker: Status: 500; ErrorMessage: <nil>; Description: unable to find originating identity; ResponseError: <nil>

I think I am missing something in my broker? But when the osb-broker-starter-pack was bumped to 0.0.2 nothing was changed in the broker code. So I am not sure what would need to be done in the broker side?

cc @pmorie @shawn-hurley

Unable to deploy broker skeleton

Hello, I am interested in using your starter-pack to implement a service broker in kubernetes. I followed the instructions and I am getting the following error:

ubuntu@cf-broker-master:~/go/src/github.com/pmorie/osb-starter-pack$ make deploy-helm
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 \
go build -o servicebroker-linux --ldflags="-s" github.com/pmorie/osb-starter-pack/cmd/servicebroker
cp servicebroker-linux image/servicebroker
docker build image/ -t "quay.io/osb-starter-pack/servicebroker:125abe3"
Sending build context to Docker daemon  5.736MB
Step 1/3 : FROM busybox
 ---> 5b0d59026729
Step 2/3 : ADD servicebroker /opt/servicebroker/servicebroker
 ---> Using cache
 ---> a9422d727793
Step 3/3 : CMD /opt/servicebroker/servicebroker --help
 ---> Using cache
 ---> 06ed501e4358
Successfully built 06ed501e4358
Successfully tagged quay.io/osb-starter-pack/servicebroker:125abe3
helm upgrade --install broker-skeleton --namespace broker-skeleton \
charts/servicebroker \
--set image="quay.io/osb-starter-pack/servicebroker:125abe3",imagePullPolicy="IfNotPresent"
Error: UPGRADE FAILED: "broker-skeleton" has no deployed releases
Makefile:31: recipe for target 'deploy-helm' failed
make: *** [deploy-helm] Error 1

Seems like the build process works well but the install is not working. Not sure why is using image quay.io/osb-starter-pack/servicebroker:125abe3 instead of :latest

Any help is much appreciated.

Thanks!

Helm install failing with `no kind "ClusterServiceBroker"`

The Helm chart is failing to install with the following error message:

helm upgrade --install broker-skeleton --namespace broker-skeleton \
	charts/servicebroker \
	--set image="<redacted>",imagePullPolicy="IfNotPresent"
Release "broker-skeleton" does not exist. Installing it now.
Error: unable to decode "": no kind "ClusterServiceBroker" is registered for version "servicecatalog.k8s.io/v1beta1"

This appears to be related to helm/helm#2994. Changing the hook type for the ClusterServiceBroker to crd-install seems to fix it.

This repo should have a release strategy

...and ensure that the example from the README works correctly as written there.

Created from #66

First integration test

Let's make an integration test that:

• stubs out the BusinessLogic with a fake that just returns a fixed catalog
• uses go-open-service-broker-client to send a catalog request to an instance of this broker
• verifies that the catalog from (1) is reflect.DeepEqual to the one received by the client

CI should verify that this project can be successfully deployed

Ideally, there would be jobs that checked:

• Deployment using helm
• Deployment using openshift templates

Return Exists in the Response

Now that pmorie/osb-broker-lib#28 is merged and in a release, we should have an example for this in this project as well. Not sure what is the correct approach, but would be good if we could along the way fix #82 as well? :)

cc @shawn-hurley

'extra' parameters to BusinessLogic operations should be encapsulated in a 'request context' object

...to avoid future signature changes if we add new things beyond the ResponseWriter and original HTTPRequest.

How can I change the name of the cluster service class

I would like to change the service and external names of the cluster service class:
4f6e6cf6-ffdd-425f-a2c7-3c9258ad246a example-starter-pack-service

I thought that this information was in the file pkg/broker/logic.go, inside the function GetCatalog() But the changes to the Name; ID or Description don't have any effect after running the "make push deploy-openshift" command.

What is the correct place to change this names?

Regards

Jose Jerez

Add support for OriginatingIdentity

... for provision, update, deprovision, bind, and unbind per the spec

Improve doc!

We should have:

• goals
• how to develop
• how to rebase!