订阅我们的博客

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.


关于作者

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事