Today, each WTO release is associated with a version of OpenShift. For instance, WTO 1.10 can only be installed on OpenShift 4.15 or higher.

This results in multiple versions of WTO being supported at once. As each version of WTO is productized, fresh maker respins for CVE's will occur for each supported version. Releasing a freshmaker respin of WTO requires manual effort to modify the OLM CSV, which can be a time-consuming process. This is compounded by the fact that all currently supported version of WTO may require manual intervention as a result of a freshmaker respin.

Additionally, there are instances where a CVP test that was non-gating (or non-existent) at the time of a WTO version release becomes a gating test later on during the version's lifecycle. If a freshmaker respin occurs in cases like these, manual intervention is required to make the gating-test pass so that the updated release can occur.

Thus, in an effort to reduce duplicate labour for each version of WTO, it would be ideal to have all supported versions of OCP use the same version of WTO.

So far, there are 2 considerations that must be kept in mind for this to work:

• Each currently supported of WTO must have an OLM upgrade path to the latest version of WTO. For example, if WTO 1.11 were to support all versions of OLM, then WTO 1.7 must be upgradeable to WTO 1.11
• The binaries shipped in the Web Terminal Tooling container must match the cluster which they are used on, as the binaries may not necessarily be compatible with older cluster versions. For example, oc 4.15 may not be compatible with OCP 4.12.
  • A potential solution here would be to dynamically detect the cluster's versions of OpenShift and install the appropriate binaries. This is already being done for certain tooling shipped in WTO, such as kn (the knative CLI): https://github.com/redhat-developer/web-terminal-tooling/blob/main/etc/cli-wrappers/kn