Bump controller runtime to avoid mistakenly defaulting to wrong mapper

[akalenyu]

What this PR does / why we need it:
Today, controller runtime mistakenly ignores the inherited Manager default
dynamic mapper and uses a discovery mapper instead:
kubernetes-sigs/controller-runtime#2491
This means that if some CRD was not available on the cdi-controller startup,
Even if it got installed after, we would still get IsNoMatch when trying to access it.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
https://bugzilla.redhat.com/show_bug.cgi?id=2237470

Special notes for your reviewer:

Release note:

BugFix: If a CRD wasn't available during controller startup, our client would keep failing to get the objects,
mistakenly returning NoMatchError even if the CRD was installed since

[akalenyu]

/hold
lets get thoughts first, maybe we can live with discovery mapper peacefully for a while
we will switch to latest ctrl runtime in main soon, so this is mainly about backporting to releases

[alromeros]

Just wondering if this PR would still be necessary if your controller-runtime fix merges. As I understand, your PR kubernetes-sigs/controller-runtime#2491 fixes the issue in controller runtime v0.14, which is used in our older maintained releases. We don't have to worry about future releases since v0.15-0.16 doesn't have this issue and we plan to update soon. Is this PR still necessary, then?

[akalenyu]

Just wondering if this PR would still be necessary if your controller-runtime fix merges. As I understand, your PR kubernetes-sigs/controller-runtime#2491 fixes the issue in controller runtime v0.14, which is used in our older maintained releases. We don't have to worry about future releases since v0.15-0.16 doesn't have this issue and we plan to update soon. Is this PR still necessary, then?

So we have the Bugzilla linked in this PR that triggered this investigation to begin with;
Basically, OpenShift routes were not available for some reason at the controller startup time, and since we use
the "wrong" mapper (non-dynamic one) our client can never get routes anymore until the controller pod is restarted.
There could be other pain points with using a non-dynamic mapper, or, we may be able to live with it
until controller runtime PR merges, a 0.14.z is made, and that is used in CDI.

Just wondering if this PR would still be necessary if your controller-runtime fix merges.

Yeah, this is the main question. If we decide that it's too painful that the client never recovers,
we may not be able to wait until the controller runtime release makes it's way to us.

[akalenyu]

/hold cancel

[awels]

/lgtm
/approve

[awels]

/cherrypick release-v1.58

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: awels

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 [awels]

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

[kubevirt-bot]

@awels: once the present PR merges, I will cherry-pick it on top of release-v1.58 in a new PR and assign it to you.

In response to this:

/cherrypick release-v1.58

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.

[akalenyu]

/retest

[akalenyu]

/retest

[kubevirt-bot]

@awels: new pull request created: #2977

In response to this:

/cherrypick release-v1.58

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.

[akalenyu]

/cherrypick release-v1.57

[kubevirt-bot]

@akalenyu: #2896 failed to apply on top of branch "release-v1.57":

Applying: Bump controller runtime to avoid mistakenly defaulting to wrong mapper
Using index info to reconstruct a base tree...
M	go.mod
M	go.sum
M	vendor/modules.txt
Falling back to patching base and 3-way merge...
Auto-merging vendor/modules.txt
CONFLICT (content): Merge conflict in vendor/modules.txt
Auto-merging go.sum
CONFLICT (content): Merge conflict in go.sum
Auto-merging go.mod
CONFLICT (content): Merge conflict in go.mod
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Bump controller runtime to avoid mistakenly defaulting to wrong mapper
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherrypick release-v1.57

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.