-
Story
-
Resolution: Done
-
Major
-
None
-
5
-
False
-
False
-
NEW
-
NEW
-
Undefined
-
-
Logging (LogExp) - Sprint 206, Logging (LogExp) - Sprint 207
As an OpenShift-Logging Engineer, I want to leverage openshift-logging operand images across releases to lower the maintenance burden for operand changes across releases.
Background
Historically OpenShift Logging was part of the OpenShift ART release procedures that required that all repositories and accompanying images built from them under the GH org openshift need to follow the branch-cut release approach. This meant that operators (e.g. cluster-logging-operator) as well as operand images (e.g. fluentd) were released as `release-4.y` images. This had the following impact, e.g.:
- Fixing a CVE in and operand for the latest `release-4.y` required duplicate work via backporting to `release-4.y-1`.
- Updating a vendored dependency in an operand for the latest `release-4.y` required duplicate work via backporting to `release-4.y-1`.
Since Jan 2021 OpenShift Logging is decoupled from ART and maintains its own release faith via CPaaS. However we kept the old release approach by cutting `release-5.y` for operators as well as for operands.
Proposed approach
Going forward by implementing the following approach we want to maintain the operand images as:
- All operand images are maintained only origin-aggregated-logging master branch.
- CI builds of operand images promote image version as:
- elasticsearch: 6.8.1
- kibana: 6.8.1
- curator: 5.8.1
- fluentd: 1.7.4
- In addition to the OAL operands, two other operands are maintained under their openshift org repos from master branch as:
- elasticseach-proxy: 1.0 (New release numbering from now on)
- eventrouter: 0.3
- Builds and PRs in origin-aggregated-logging, openshift/elasticsearch-proxy and openshift/eventrouter are gated by:
- E2E tests from CLO & EO from master
- E2E tests from CLO & EO from active operator releases, e.g. `release-5.2`, `release-5.1`, `release-5.0
- Midstream and Downstream are required to follow and publish operand images as CI builds, e.g. image logging-elasticsearch6-6.8.1-1 (last number after dash is build number).
Additional Handling on operand breaking changes
On the likely event that one operand introduces a version bump with breaking changes, the approach to follow looks like the following example for elasticsearch. Assuming all active releases (5.2, 5.1, 5.0) require Elasticsearch 6.8.1 and 5.3 introduces 7.11.1:
- Create a release branch branch on OAL for Elasticsearch 6.8.1: `release-es-6.8.1`
- Configure midstream for 5.2, 5.1 and 5.1 to pull elasticsearch from upstream branch `release-es-6.8.1`
- Keep new release 5.3 in midstream to pull the new elasticsearch image from upstream branch `master`.
- Configure midstream for 5.3 to update Dockerfile.in for elasticsearch to version: `7.11.1`
Examples
For an active release 5.1.1
Assuming all above is implemented, listing builds for example for elasticsearch6 via brew provides the following output:
$ brew list-builds --package=logging-elasticsearch6-container
logging-elasticsearch6-container-v6.8.1-1 contra/pipeline COMPLETE
logging-elasticsearch6-container-v6.8.1-2 contra/pipeline COMPLETE
logging-elasticsearch6-container-v6.8.1-3 contra/pipeline COMPLETE
When we look on the brew tag for our active release via brew we should get the operand attached as:
$ brew list-pkgs --tag=openshift-logging-5.1-rhel-8 Package Tag Extra Arches Owner -------------------------------- ---------------------------- ---------------- --------------- ... logging-elasticsearch6-container openshift-logging-5.1-rhel-8 jcantril ...
Asking for the latest build of that component for the tag openshift-logging-5.1-rhel-8 should provide:
$ brew latest-build openshift-logging-5.1-rhel-8 --all Build Tag Built by ----------------------------------------------------- ---------------------------- ---------------- cluster-logging-operator-container-v5.1.1-4 openshift-logging-5.1-rhel-8 contra/pipeline cluster-logging-operator-metadata-container-v5.1.1-13 openshift-logging-5.1-rhel-8 contra/pipeline elasticsearch-operator-container-v5.1.1-3 openshift-logging-5.1-rhel-8 contra/pipeline elasticsearch-operator-metadata-container-v5.1.1-13 openshift-logging-5.1-rhel-8 contra/pipeline elasticsearch-proxy-container-v1.0.0-3 openshift-logging-5.1-rhel-8 contra/pipeline logging-curator5-container-v5.8.1-4 openshift-logging-5.1-rhel-8 contra/pipeline logging-elasticsearch6-container-v6.8.1-3 openshift-logging-5.1-rhel-8 contra/pipeline logging-eventrouter-container-v0.3.0-3 openshift-logging-5.1-rhel-8 contra/pipeline logging-fluentd-container-v1.7.4-4 openshift-logging-5.1-rhel-8 contra/pipeline logging-kibana6-container-v6.8.1-3 openshift-logging-5.1-rhel-8 contra/pipeline
For a release in development 5.2.0
When we look on the brew tag for our active release via brew we should get the operand attached as:
$ brew list-pkgs --tag=openshift-logging-5.2-rhel-8-candidate Package Tag Extra Arches Owner -------------------------------- -------------------------------------- ---------------- --------------- ... logging-elasticsearch6-container openshift-logging-5.2-rhel-8-candidate jcantril ...
Asking for the latest build of that component for the tag openshift-logging-5.2-rhel-8-candidate should provide:
$ brew latest-build openshift-logging-5.1-rhel-8 --all Build Tag Built by ----------------------------------------------------- -------------------------------------- ---------------- cluster-logging-operator-container-v5.2.0-4 openshift-logging-5.2-rhel-8-candidate contra/pipeline cluster-logging-operator-metadata-container-v5.2.0-13 openshift-logging-5.2-rhel-8-candidate contra/pipeline elasticsearch-operator-container-v5.2.0-3 openshift-logging-5.2-rhel-8-candidate contra/pipeline elasticsearch-operator-metadata-container-v5.2.0-13 openshift-logging-5.2-rhel-8-candidate contra/pipeline elasticsearch-proxy-container-v1.0.0-3 openshift-logging-5.2-rhel-8-candidate contra/pipeline logging-curator5-container-v5.8.1-4 openshift-logging-5.2-rhel-8-candidate contra/pipeline logging-elasticsearch6-container-v6.8.1-3 openshift-logging-5.2-rhel-8-candidate contra/pipeline logging-eventrouter-container-v0.3.0-3 openshift-logging-5.2-rhel-8-candidate contra/pipeline logging-fluentd-container-v1.7.4-4 openshift-logging-5.2-rhel-8-candidate contra/pipeline logging-kibana6-container-v6.8.1-3 openshift-logging-5.2-rhel-8-candidate contra/pipeline
Note: Not yet released builds are always attached to a candidate brew tag, e.g. openshift-logging-5.2-rhel-8-candidate