Add release image validation for NodePools

[enxebre]

What this PR does / why we need it:
Add release image validation for NodePools:

• Move existing HC release image validation into support/ package.

Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
ref https://issues.redhat.com/browse/HOSTEDCP-543

Checklist

• Subject and description added to both, commit and PR.
• Relevant issues have been referenced.
• This change includes docs.
• This change includes unit tests.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enxebre

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [enxebre]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[csrwng]

@enxebre I think this is good, but for nodepools we can't just validate the release on its own. We need to validate it in relation to the HC version. My initial thought is that we should not allow creating a new nodepool to anything other than the HC release version. And when upgrading a nodepool we should only be able to upgrade it to the current HC version.

[enxebre]

@enxebre I think this is good, but for nodepools we can't just validate the release on its own. We need to validate it in relation to the HC version. My initial thought is that we should not allow creating a new nodepool to anything other than the HC release version. And when upgrading a nodepool we should only be able to upgrade it to the current HC version.

I agree, the PR is already validating against the HC as the latest supported version https://github.com/openshift/hypershift/pull/1709/files#diff-c666a2a9dc48b0d3de33cc8fa3a054f853671f0428f9d56b263750dfc6d26e00R1360-R1365

[csrwng]

I agree, the PR is already validating against the HC as the latest supported version https://github.com/openshift/hypershift/pull/1709/files#diff-c666a2a9dc48b0d3de33cc8fa3a054f853671f0428f9d56b263750dfc6d26e00R1360-R1365

But should we allow a version < HC's (on creation)?

[enxebre]

But should we allow a version < HC's (on creation)?

We can not prevent creation of anything, i.e as soon as the resource is applied it's persisted, then in the backend we do the validation and short circuit reconciliation. In the reconciliation loop there's no means to differentiate between create/update (or may be we could you .generation?). The backend validating against hc.release as latest allowed and letting webhook/cli validate/default to hc.version for creation makes sense to me.

Did you have something different in mind for this?

[csrwng]

As discussed earlier today, it's fine to proceed with this validation and separately enable the webhook to do a more fine grained validation.

[enxebre]

/retest

[enxebre]

/test e2e-aws

[csrwng]

/lgtm

[openshift-ci]

@enxebre: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-nested	acf9837	link	true	/test e2e-aws-nested
ci/prow/e2e-kubevirt-gcp-ovn	acf9837	link	false	/test e2e-kubevirt-gcp-ovn
ci/prow/capi-provider-agent-sanity	95d16af	link	false	/test capi-provider-agent-sanity

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.