Crossplane Service Broker

Open Service Broker API which provisions Redis and MariaDB instances via crossplane.

Documentation

Most of the explanation on how this all works together currently lives in the VSHN Knowledgebase.

Contributing

You'll need:

A running kubernetes cluster (minishift, minikube, k3s, ... you name it) with crossplane installed
kubectl and kustomize
Go development environment
Your favorite IDE (with a Go plugin)
docker
make

These are the most common make targets: build, test, docker-build, run.

Folder structure overview

.
├── cmd
│   └── crossplane-service-broker    # main file
├── deploy
│   └── base                         # deployment files
├── docs                             # antora docs
├── e2e                              # e2e testing files
├── pkg
│   ├── api                          # exposed HTTP API server
│   ├── brokerapi                    # service broker implementation
│   ├── config                       # app config
│   ├── crossplane                   # crossplane service layer
│   ├── integration                  # utilities for integration tests
│   └── reqcontext                   # request context mapping
└── testdata                         # integration testing files

Run the service broker

You can run the operator in different ways:

using make run (provide your own env variables)
using make kind-run (uses KIND to install a cluster in docker and provides its own kubeconfig in testbin/)
using a configuration of your favorite IDE (see below for VSCode example)

Example VSCode run configuration:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch",
      "type": "go",
      "request": "launch",
      "mode": "auto",
      "program": "${workspaceFolder}/cmd/crossplane-service-broker/main.go",
      "env": {
        "KUBECONFIG": "path/to/kubeconfig",
        "OSB_USERNAME": "test",
        "OSB_PASSWORD": "TEST",
        "OSB_SERVICE_IDS": "PROVIDE-SERVICE-UUIDS-HERE",
        "OSB_NAMESPACE": "test",
        "OSB_PLAN_UPDATE_SIZE_RULES": "xsmall>small|xsmall>medium|small>medium"
      },
      "args": []
    }
  ]
}

Run integration tests

"Integration" testing is done using envtest and crossplane's integration test helper.

make integration-test

Example VSCode run configuration (to be able to debug things):

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Integration tests",
      "type": "go",
      "request": "launch",
      "mode": "test",
      "program": "${workspaceFolder}/pkg/brokerapi",
      "env": {
        "KUBEBUILDER_ASSETS": "../../testdata/bin",
        "DEBUG": "true" // optional
      },
      "args": [],
      "buildFlags": "-tags=integration"
    }
  ]
}

Run E2E tests

The e2e tests currently only test if the deployment works. They do not represent a real e2e test as of now but are meant as a base to build upon.

You need node and npm to run the tests, as it runs with DETIK.

To run e2e tests for newer K8s versions run

make e2e-test

To remove the local KIND cluster and other resources, run

make clean

Integration tests

The integration tests aren't very clever yet and will need some improvements to catch issues. They set the boundary at Kubernetes and avoid therefore the need to have a working crossplane installation with all the custom resources necessary set up.

This means that certain kinds of bugs can't be catched (interaction between crossplane provisioner and this code).

All integration tests are currently within the brokerapi package. envtest is used to setup a Kubernetes API server, and an etcd instance. Public CRDs from crossplane are being downloaded on first run, while the CRDs for this service broker are manually copied in and live within testdata/crds/*.syn.tools.yaml.

If tests for CRDs within the syn.tools API group are written, ensure the corresponding CRD definition is within the aforementioned directory.

Implement Async Bindings

Summary

As a service broker user
I want bindings to report an accurate status
So that I can rely on this status to know if a binding is ready and usable

Context

Currently bindings are always done synchronously. Using the accepts_incomplete query parameter a client can allow async bindings. Especially if it takes several minutes for the binding to become ready (e.g. user/grant provisioned) it's helpful to reflect the current state of a binding: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#polling-last-operation-for-service-bindings

https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#request-creating-a-service-binding

It's important to still support sync bindings as well since not all clients support async bindings yet.

Out of Scope

List aspects that are explicitly not part of this feature

Further links

Acceptance criteria

Given a client specifies accepts_incomplete=true
When a binding is created
Then it's being done in an asynchronous manner and the status is reported

Implementation Ideas

Same as the implementation of async instance provisioning
- Create the Composite instance
- Poll the composite's status via /last_operation
- Return credentials once the composite is ready

vshn / crossplane-service-broker Goto Github PK