Add OCP version compatibility check before installation

[p-rog]

Summary

• Add a pre-flight OCP version compatibility check to pattern.sh that detects the target cluster version and warns the user before installing on unsupported OCP streams
• Introduce compatibility.json as a machine-readable compatibility matrix defining supported versions and known issues

Motivation

Installing ZTVP on an unsupported OCP version (e.g., 4.22) silently proceeds and then fails with subscription errors (ZTWIM operator missing from catalog, ACM channel mismatch). The user gets no feedback
until ArgoCD applications go unhealthy. This check catches the problem before any cluster resources are deployed.

How it works

The check_compatibility function in pattern.sh runs on the host before the utility container is launched:

1. Reads compatibility.json from the repo root
2. Detects the cluster version via oc (falls back to kubectl)
3. If the version is supported — prints a confirmation and continues
4. If unsupported — prints a warning with known issues and prompts the user to confirm or abort

Bypass mechanisms

• SKIP_COMPATIBILITY_CHECK=true ./pattern.sh make install — skips entirely
• Answering y at the prompt — proceeds with warning acknowledged
• Removing compatibility.json — disables the feature

Graceful fallbacks

No oc/kubectl on host, no python3, or no compatibility.json — the check is silently skipped and installation proceeds normally.

Tested

• Supported OCP version (4.21) — green confirmation, installation proceeds
• Unsupported OCP version (4.22) — warning with known issues displayed, user prompted
• User accepts prompt — installation proceeds
• User declines prompt — installation aborted
• SKIP_COMPATIBILITY_CHECK=true — check skipped
• No compatibility.json — check skipped

Next steps

We can extend this and make it default part of the VP framework and compatibility.json can be added to patterns who would like to adopt it. We can also update the graphical pattern installation in a similar way. Other tests can be added based on the compatibility.json as well in the future.

[mlorenzofr]

For integration with VP, perhaps the best place to perform these checks would be in the utility-container, and within the ansible collection rhvp.cluster_utils.

Not only is it better integrated, but the container and ansible also have a number of tools that would make our lives easier and allow us to avoid the python script.

As for the rest, the JSON validation design seems good to me. Perhaps it would be good to have a JSON validation scheme with attributes and their types for validation purposes.

[mlorenzofr]

Perhaps instead of using an inline script within bash, it would be better to separate it into a separate script. This way, we can take a more development-oriented approach, such as ensuring that linters are passed, controlling its style, and so on.

The other option is to implement the same functionality via shell scripting using jq. However, as I mentioned in the review message, perhaps the appropriate place for this functionality, and for better integration with VP, would be the rhvp.cluster_utils collection.

[p-rog]

Let's discuss where to put this functionality as the best place.

[mlorenzofr]

Suggested change

	with open(compat_file) as f:
	with open(compat_file, encoding="utf-8") as f:

[mlorenzofr]

The clusterversion resource is specific to OpenShift (CVO). This doesn't mean it won't work with kubectl, it's a CRD, but I don't know how many people will actually use kubectl with OpenShift instead of using oc.

Perhaps it would detect which CLI is being used and then use it, thus avoiding this if statement and the repetition of cluster_version=.... which is the same in both cases except for the CLI:

local kube_cli
kube_cli=$(command -v oc 2>/dev/null) || kube_cli=$(command -v kubectl 2>/dev/null) || true

if [ -n "$kube_cli" ]; then
  cluster_version=$($kube_cli get clusterversion ...
fi

[mlorenzofr]

Instead of a string, we could use a list. This way, we could add multiple messages to the same version if needed.