Automation Broker Versioning

The Automation Broker is preparing for OpenShift Container Platform (OCP) 3.10. With several releases of the Broker (formerly Ansible Service Broker) we wanted to take a few moments to communicate our release strategy. This blog post is designed to document a few things:

  1. The Automation Broker’s versioning strategy.
  2. Which version of the Broker targets a given a version of Kubernetes or OpenShift.
  3. The Broker’s compatibility with APBs.
  4. Deploying the Broker in Kubernetes or OpenShift.

Automation Broker Version Strategy

The first official release of the broker, 1.0.x, targeted OpenShift Origin release v3.7.0. Following the versioning rules (see Version Format below), the version was bumped to 1.1.x for OpenShift Origin release v3.9.0 and again to 1.2.x for OpenShift Origin release v3.10.0.

Version Format

The Broker version is stored in the broker’s RPM spec file, ansible-service-broker.spec, and is in the form of MAJOR.MINOR.PATCH incremented by the following rules:

  • MAJOR version when incompatible API changes are made.
  • MINOR version when a new version of openshift/origin is being targeted.
  • PATCH version when tagged via tito tag.

Branching

All of our development work is done on the master branch. New branches are created when a submitted Pull Request is targeting a future release. This is done when the Broker is under feature freeze to allow for development work to continue when the targeted release is being hardened. When a new branch is created, it will be named release-MAJOR.MINOR and the version in the master branch will be bumped based on the rules in Version Format.

Broker Releases

Kubernetes Version OpenShift Version Broker Version Broker Branch Name
1.7 3.7 1.0 release-1.0
1.9 3.9 1.1 release-1.1
1.10 3.10 1.2 N/A*
1.11 3.11 1.3 N/A*
Kubernetes Version OpenShift Version Broker Version Broker Branch Name
1.7 3.7 1.0 release-1.0

Broker APB Compatibility

In OCP 3.9 we introduced the APB runtime concept. Decoupling the APB that the developer writes from the APB runtime allows APB developers to develop and publish their APBs without concerning themselves with how the Broker and APB communicate in cluster. By applying a label (com.redhat.apb.runtime) to the base APB container image, the Broker is able to recognize how to interact with the running APB. However, since this concept was introduced in OCP 3.9, version 1.0.x versions of the Broker (aligned with OCP 3.7) do not know how to interact with new APB container images. It is for this reason that we tagged release-1.0 APB container images.

Deploying the Broker in Kubernetes or OpenShift

We like APBs so much that we wrote one for installing (and uninstalling) the Broker in a cluster. You can find our latest install.yaml in the apb directory of the broker project. Release branches of the Broker contain one also (ie. release-1.1). To install:

$ wget https://raw.githubusercontent.com/openshift/ansible-service-broker/master/apb/install.yaml
$ kubectl create -f install.yaml

Conclusion

In this blog post we talked about the Broker’s versioning strategy, Broker releases and how they line up with different version of Kubernetes and Openshift, the Broker’s APB compatibility, as well as method for reliably installing the Broker in Kubernetes and OpenShift. You can find us online at automationbroker.io, @autom8broker on Twitter, and #asbroker on Freenode.

Categories
Kubernetes, OpenShift Container Platform
Tags
, , , ,