Slides 

Downstream base image compatibility with OCP releases

Customer Problem:

• Tight release time frame to make sure my Operator is compatible with OCP release. (See slide 5)
• Figure out what version of base image they should use so their Operators are compatible with OCP.

Operator teams (ISVs or internal) builds Operators with Red Hat’s downstream base image, which is released "some time" before OCP 4.y GA (tag: v4.y). Currently, these downstream base images only have been tested with ‘one OCP version’.
e.g. img tag: v4.7 has only been tested with OCP 4.7.

This means for Operators built with v4.y base image are not guaranteed to work with OCP after OCP 4.y+1 is released (see the "gray bars" in slide 5).

Operator teams only have a fairly tight time frame to rebuild and release a newer version built with v4.y+1 base image.
Otherwise, it's either "their Operators are not guaranteed to work with the latest available OCP release" or, on the flip side, "their Operator would block the OCP 4.7 cluster upgrade".

Epic Goal

• The downstream base image we released (as v4.y) is guaranteed to work with both OCP4.y and 4.y+1. (See slide 6, slide 7)
• For EUS, the downstream base image is guaranteed to work with OCP (through base image z-stream) until the next OCP EUS version. (See slide 6, slide 12, slide 13)

Why is this important?

• As an Operator developer, I want to make sure the Red Hat downstream base image I used for my Operator(v4.y) will work with both OCP4.y and 4.y+1.
  • This way, I have reasonable time to build and release a newer Operator version using v4.y+1 base image without having my Operator being not compatible with OCP 4.y+1 nor blocking the OCP upgrade.

• As an Operator developer, I want to make sure the Red Hat downstream base image I used for my Operator for EUS (v4.6) will continue work with OCP until the next OCP EUS release.
  • And if the base image were incompatible with the OCP over the course, I get the base image patch releases from Red Hat so I can release a patch version for my Operators. See slide

Acceptance Criteria

• In addition to the current base image (e.g. v4.y+1) testings against the current OCP release (e.g. OCP 4.y+1), add another testing with the previous base image (e.g. v4.y) against the current OCP (e.g. OCP 4.y+1) to make sure the base image works fine in two consecutive OCP releases. As an example:
  • During 4.7 feature development, SDK should test:
    • existing 4.6 base image against nightly 4.7 OCP builds
    • current SDK master builds against nightly 4.7 OCP builds
  • After 4.7 feature freeze (before code freeze, SDK should test:
    • existing 4.6 base image against nightly 4.7 OCP builds
    • current SDK release-4.7 builds against nightly 4.7 OCP builds
  • Operator based on 4.6 base image successfully transitions during cluster upgrade from OCP 4.6 to OCP 4.7

• Document/highlight in the release note of base image v4.y if any APIs will be removed/stopped supporting in base image v4.y+1, so users are aware of avoiding using those in their Operator project with base image v4.y.
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>