블로그 구독

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

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리