⚠️ Bump controller-runtime 0.13.1=>0.14.1

[aniruddha2000]

Signed-off-by: Aniruddha Basak [email protected]

What this PR does / why we need 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):
Part of #7671

cc @kubernetes-sigs/cluster-api-release-team

[sbueringer]

/retitle ⚠️ Bump controller-runtime 0.13.1=>0.14.1

[ykakarap]

Looks like this version of controller-runtime introduced some breaking changes.
There are a few lint issue that need to be addressed. Running the linter locally I see the following issues:

• The ValidateLabelSelector function signature changed. Passing an empty options object (metav1validation.LabelSelectorValidationOptions{}) as the second argument, at every use, should be enough to fix that.
• sets.String seems to be deprecated and now the recommendation seems to be to use generics to create a set. Doing that switch is out of scope for this PR. Let's do it in a separate PR. So for now, I would suggest adding an exception in the linter for the scope of this PR and address it in a follow up PR.
• controller-runtime's client.Client interface changes and the dryrun.Client struct no longer implements the interface correctly. I would suggest adding the required functions to the dryrun.Client struct should be enough for this PR. I will need more time to see if we can get away with an "empty" implmentation as the dryrun client does not operate on subresources.

[sbueringer]

Changes lgtm pending what is mentioned in this thread: #7906 (comment)

[aniruddha2000]

Lint passed but seems there are a lot of complicated breaking changes now 😵‍💫

[sbueringer]

@aniruddha2000 I can take a look at it and then open a PR against your branch if you want

[aniruddha2000]

@sbueringer sure!

[sbueringer]

@sbueringer sure!

Will do. Looks like some of the failures are related to some things I identified once I got a chance to catch up with controller-runtime yesterday (#7925)

[sbueringer]

@aniruddha2000 PR is open here: aniruddha2000#10
Maybe just merge it so my change will end up on the current PR.

Then we can take it from there.

The problem was essentially that fake client now supports indexes and we have to add them to the fake client explicitly

[sbueringer]

/test pull-cluster-api-e2e-full-main

[sbueringer]

Thx!
Can you please squash the commits?

/lgtm

/assign @fabriziopandini @ykakarap

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: e69272945ee3f1e81fd68c7d4c2d0bb1244c9df3

[ykakarap]

LGTM pending squash.

Just minor nits.

Thank you @aniruddha2000 for all the work! 🚀

[fabriziopandini]

/lgtm

[aniruddha2000]

Squash done

[sbueringer]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 8ee3d6f0046b86c2177f0dc6db4aa026cf102135

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

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

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

[RainbowMango]

Hi @kubernetes-sigs/cluster-api-release-team,

Could you please tag a new patch release to include this?

We(Karmada project) are going to bump Kubernetes(v1.26) and controller-runtime(v0.14.1), but we are blocked by cluster-api because we are using [email protected].

I checked the latest release v1.3.2 which does not include this patch.
I'd like a new tagged release from cluster-api, like v1.3.3?

# sigs.k8s.io/cluster-api/api/v1beta1
vendor/sigs.k8s.io/cluster-api/api/v1beta1/machineset_types.go:180:83: not enough arguments in call to metav1validation.ValidateLabelSelector
	have (*"k8s.io/apimachinery/pkg/apis/meta/v1".LabelSelector, *field.Path)
	want (*"k8s.io/apimachinery/pkg/apis/meta/v1".LabelSelector, validation.LabelSelectorValidationOptions, *field.Path)

[killianmuldoon]

@RainbowMango according to the release timeline - https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-1.4.md#timeline - there should be release of v1.3.3 this week.

[furkatgofurov7]

@RainbowMango according to the release timeline - https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-1.4.md#timeline - there should be release of v1.3.3 this week.

@killianmuldoon this was merged to main and not back-ported to release-1.3 branch AFAIU, so I would not expect to have these changes in the new patch release (v1.3.3).

[RainbowMango]

OK, that makes sense. For now, I can use a pseudo version from the main branch(like v1.3.0-rc.0.0.20230127161026-14ffcb25bbf2), and change it to v1.4.0 after v1.4.0 is released.

Thanks @killianmuldoon @furkatgofurov7. That really helps.

[sbueringer]

For clarification. We consider bumping controller runtime and k8s.io/* dependencies breaking changes. Thus this won't be backported.