fix: validation for new default ocp versions

[aamadeuss]

Description

Fixes ocp version validation for worker_pools so it does not fail for a newly released default version.
Added a data block look up to fetch the currently supported OCP versions so that versions added in the future will not need to be added separately in the validation.
Fixes #849

Release required?

• No release
• Patch release (x.x.X)
• Minor release (x.X.x)
• Major release (X.x.x)

Release notes content

• Prevents validation failure when default ocp version is changed to a newer version, as well as when newer ocp versions are supported.

Run the pipeline

If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.

Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:

/run pipeline

Checklist for reviewers

• If relevant, a test for the change is included or updated with this PR.
• If relevant, documentation for the change is included or updated with this PR.

For mergers

• Use a conventional commit message to set the release level. Follow the guidelines.
• Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
• Use the Squash and merge option.

[vkuma17]

looks good

[aamadeuss]

/run pipeline

[vkuma17]

just noticed that as per this logic 4.14 with rhcos will still work here which is not supported but since 4.14 is returned as a valid version from the list final contains condition will evaluate to true

[vkuma17]

Need some logic update, current logic will completely ignore OS checks

[vkuma17]

LGTM

[aamadeuss]

/run pipeline

[vkuma17]

@aamadeuss one more small change is required. right now for version 4.20 and higher we only validate if its a valid version and no validations on OS.

starting 4.21 onwards, only RHCOS will be supported and in 4.20 RHCOS and RHEL 9 will both be supported, so for now can we just add another condition just for 4.20 similar to 4.19 and another condition checking all versions >= 4.21 and OS = "RHCOS"

[aamadeuss]

/run pipeline

[aamadeuss]

Retrying pipeline as it seems to be working now

[aamadeuss]

/run pipeline

[aamadeuss]

/run pipeline

[aamadeuss]

2025/11/25 08:20:53 �[1m�[31mThere was an internal Error. Please verify the resources and retry after some time.�[39m�[0m

Pipeline failed because of schematics test, retrying

[aamadeuss]

/run pipeline

[ocofaigh]

This does not really achieve what we want. Your still hard coding versions here (you just added 4.20 and 4.21 which don't even exist yet). The goal here is to see if we can have logic that does not require hard coding versions. Alternatively, I suggested that we actually test what happens if we remove the validation. Will the provider catch unsupported OS if tried? Does it fail at plan or apply?

Maybe if we know an OS is longer supports after a certain version, we check for that. For example we know RHEL8 does not work after a certain version. Lets validate that. And then as Operating system versions are deprecated in later versions, we add validation for those. But what we don’t want is validation failing on new versions for operating systems that are supported. Like what happened when we moved to 4.19

[vkuma17]

This does not really achieve what we want. Your still hard coding versions here (you just added 4.20 and 4.21 which don't even exist yet). The goal here is to see if we can have logic that does not require hard coding versions. Alternatively, I suggested that we actually test what happens if we remove the validation. Will the provider catch unsupported OS if tried? Does it fail at plan or apply?

Maybe if we know an OS is longer supports after a certain version, we check for that. For example we know RHEL8 does not work after a certain version. Lets validate that. And then as Operating system versions are deprecated in later versions, we add validation for those. But what we don’t want is validation failing on new versions for operating systems that are supported. Like what happened when we moved to 4.19

@ocofaigh i agree that we are still hardcoding versions but this PR is future proof... we hardcoded 4.20 because, 4.20 is going to support both RHCOS and RHEL9 while from 4.21 onwards only RHCOS will be supported. With this change, we don't need to make any changes afterwards even with 4.22 and onward versions
Reference doc: https://cloud.ibm.com/docs/openshift?topic=openshift-rhel_migrate&interface=ui

[terraform-ibm-modules-ops]

🎉 This PR is included in version 3.73.3 🎉

The release is available on:

• GitHub release
• v3.73.3

Your semantic-release bot 📦🚀