chore: Bump CAPI to v1.4.3

[Ankitasw]

What type of PR is this?
/kind support

What this PR does / why we need it:
This PR bumps CAPI to v1.4.3.

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 #

Special notes for your reviewer:

Checklist:

• squashed commits
• includes documentation
• adds unit tests
• adds or updates e2e tests

Release note:

Bump CAPI to v1.4.3

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e-blocking

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e-blocking

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e-blocking

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e-eks

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e

[Ankitasw]

/cherry-pick release-2.1

[k8s-infra-cherrypick-robot]

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

In response to this:

/cherry-pick release-2.1

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.

[Ankitasw]

PR is up for review.

[Ankitasw]

/retest

[richardcase]

@Ankitasw - there are a lot of changes in here that aren't specifically related to bumping CAPI to v1.4.3.

I'd say that we shouldn't change the return values of the reconcoleNormal/reconcileDelete functions to remove the ctrl.Result for 2 reasons:

• its the pattern used widely across CAPI
• There are some scenarios where we should be requeueing (and we're currently not).

[Ankitasw]

I'd say that we shouldn't change the return values of the reconcoleNormal/reconcileDelete functions to remove the ctrl.Result for 2 reasons

@richardcase I think they dealt in CAPI the same way, isn't it?
You can see changes here: https://github.com/kubernetes-sigs/cluster-api/pull/8796/files#diff-47cf5969a7a97b70232c5d97b882424745bd1ed511b29aa56f55194688ab833c

I understand that not all changes are related to CAPI bump, shall I revert golangci bump changes and raise another PR?

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e
/test pull-cluster-api-provider-aws-e2e-eks

[Ankitasw]

/test pull-cluster-api-provider-aws-e2e
/test pull-cluster-api-provider-aws-e2e-eks

[Ankitasw]

PR is ready for review.

[richardcase]

@richardcase I think they dealt in CAPI the same way, isn't it? You can see changes here: https://github.com/kubernetes-sigs/cluster-api/pull/8796/files#diff-47cf5969a7a97b70232c5d97b882424745bd1ed511b29aa56f55194688ab833c

Looking through the logic in the reconcileDelete/Normal, I think there are situations where we should be requeuing, and we aren't currently, so if we removed the result, then we would have to add them back in if we wanted to change these to requeue. But agree as it stands with no requeues then having the extra return value is pointless.

I understand that not all changes are related to CAPI bump, shall I revert golangci bump changes and raise another PR?

No, don't worry about it. I don't want to create unnecessary work.....plus it was more an observation.

[richardcase]

Just seen that you reverted some of the changes, sorry @Ankitasw i should've pinged you on slack to discuss.

As it stands now and with the e2e passing:

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: richardcase

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

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

[Ankitasw]

Looking through the logic in the reconcileDelete/Normal, I think there are situations where we should be requeuing, and we aren't currently, so if we removed the result, then we would have to add them back in if we wanted to change these to requeue. But agree as it stands with no requeues then having the extra return value is pointless.

Addressed this in #4326

[k8s-infra-cherrypick-robot]

@Ankitasw: #4321 failed to apply on top of branch "release-2.1":

Applying: chore: Bump CAPI to v1.4.3
Using index info to reconstruct a base tree...
M	controllers/awsmachine_controller.go
M	go.mod
M	go.sum
M	test/e2e/data/e2e_eks_conf.yaml
M	versions.mk
Falling back to patching base and 3-way merge...
Auto-merging versions.mk
CONFLICT (content): Merge conflict in versions.mk
Auto-merging test/e2e/data/e2e_eks_conf.yaml
CONFLICT (content): Merge conflict in test/e2e/data/e2e_eks_conf.yaml
Auto-merging go.sum
CONFLICT (content): Merge conflict in go.sum
Auto-merging go.mod
CONFLICT (content): Merge conflict in go.mod
Auto-merging controllers/awsmachine_controller.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 chore: Bump CAPI to v1.4.3
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:

/cherry-pick release-2.1

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.