🌱 Bump golang to v1.22

[kashifest]

This PR bumps the golang version to v1.22 in different go modules, tests and Dockerfile.

[kashifest]

/hold
This requires more discussion and project infra changes, this PR should not go in now until we have decided to bump the golang to v1.22

[kashifest]

@dtantsur @honza @zaneb when do you think we would be ready to bump golang to v1.22 for main branch in BMO, once we decide I will push changes here and in other metal3 repo's main branches accordingly

[kashifest]

/retest

[tuminoid]

/retest
Checking github action retriggering via prow.

[tuminoid]

/ok-to-test

[tuminoid]

/retest

[dtantsur]

Do we have a need to bump it? Doing so complicates local development for everyone who is not on the bleeding edge like me.

$ go version
go version go1.21.9 linux/amd64

We're also going to force the bump on any downstream consumers, whether they're ready or not.

[tuminoid]

Golang 1.21 end of support date is 2024-08-08, so we need to bump to it sooner or later. Since we need to maintain our releases for roughly a year, we'll need to bump to it release branches as well (we did the same for 1.20 -> 1.21 too when it went EOS).

So we might hold off for a while, but we need to bump it before next minor anyways. The later we do it, the less testing it gets, so there is trade-off.

[tuminoid]

Also, we already have dependencies we cannot bump, because they have moved to 1.22, like metal3-io/cluster-api-provider-metal3#1617
There will be more and more the closer we move to EOS.

[kashifest]

Yes, I agree with @tuminoid , the sooner we do it, the better, projects like k8s itself, CAPI etc have already bumped it to 1.22 in main branch, I was waiting for BMO to be ready to make it in all metal3 main branches where applicable.

[dtantsur]

Golang 1.21 end of support date is 2024-08-08, so we need to bump to it sooner or later.

I'm not following the logic. I thought the directive in go.mod only states the minimum version and users are welcome to use newer ones? My objection holds: we're pushing the change even on users of distributions that will maintain Go beyond its EOS date.

If/when we're forced to make the change because of a dependency bump, it's fine by me.

[tuminoid]

Golang 1.21 end of support date is 2024-08-08, so we need to bump to it sooner or later.

I'm not following the logic. I thought the directive in go.mod only states the minimum version and users are welcome to use newer ones? My objection holds: we're pushing the change even on users of distributions that will maintain Go beyond its EOS date.

If/when we're forced to make the change because of a dependency bump, it's fine by me.

You're correct, go.mod bump is not strictly necessary. However, when Go 1.21 reaches EOS, is there an actual reason to keep it? Users should be using Go 1.22 at that point and it is only 2 months away. We do have some deps requiring it lined up, so it will be soon at least partially forced on us as well, so IMO it is cleaner to also switch directive to go 1.22 right away when we merge.

[Rozzii]

The lack of go 1.22 in the workflows blocks this PR #1751
If we want to continue towards the gopehercloud v2 as I would suppose from the fact that we are using the beta5 version of V2, we would anyhow need to transition to Go 1.22

[dtantsur]

is there an actual reason to keep it?

The distributions don't move so quickly as we'd wish. Also, bumping Go versions should not be taken easily: I've just spent a whole morning on an enormous patch to move one of our components to Go 1.22 because the old controller-runtime segfaulted on it.

If we're forced by gophercloud, so be it. But I don't want such bumps (in go.mod specifically, not in workflows) to become a standard practice.

[kashifest]

looks like the failure in E2E fixture test was related to the test itself, it needed to setup the correct go version, so my worry about fixing the go patch version in toolchain doesnt seem to be valid which is good.

[tuminoid]

/retest

[kashifest]

/test metal3-bmo-e2e-test-pull

[Rozzii]

/lgtm

[kashifest]

/hold cancel
/cc @dtantsur @lentzi90 @honza

[lentzi90]

/approve

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lentzi90

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

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