Bump Golang to 1.17

[asmacdo]

Dependabot filed some PRs to bump go version. The CI is currently failing, but we probably aren't ready to bump yet.

#5197
#5198
#5199
#5200
#5201
#5202

[swartz-k]

Hello, I'm using 1.17 in my env and looking forward this feature. May I do something to help?

[camilamacedo86]

Hi @asmacdo,

To move with this one you need ensure the whole ecosystem first is bumped, following the order:

• k8s itself
• controller-runtime
• kubebuilder
• controller-tools
• SDK

Otherwise, we create problems for the contributor and users since is not easier to switch between go versions in the local env.

[ryantking]

kubebuilder bump being tracked here

[camilamacedo86]

Hi @ryantking,

The go version supported is 1.16
We need first bump the upper version in the projects;

• k8s
• controller-runtime
• sigs.k8s.io/kubebuilder-declarative-pattern
• then we can bump kubebuilder and by latest SDK.

Could you please check if the pre-requirements are done and if not, see if is possible to move with them first?

c/c @asmacdo

[joelanford]

TL;DR: I'm +1 on bumping since controller-runtime has, but I thought I'd provide some context around how decisions should be made around bumping Go versions.

---

Bumping the go version is different than bumping the core kubernetes library versions, right?

When a library (e.g. controller-runtime or operator-lib) bumps its Go version, it is usually to get access to some new core Go API or perhaps to force an optimization improvement made in the new Go version's compiler. In this scenario, other modules that import this library will be forced to bump their version of Go as well. Conversely, a Go developer can bump the Go version of their module before all of their dependent modules bump. The takeaway here is that library authors are typically conservative about forcing new Go versions on users, and thus do not always enforce the latest and greatest Go version to be used with their library.

When a binary bumps its version of Go, it doesn't have a direct impact on downstream consumers of the binary, so binary authers can (and often do) bump the Go version at their leisure.

With that in mind, there are two versions in question:

1. The version of go used to compile operator-sdk, helm-operator, and ansible-operator binaries. This can likely be bumped at any time since these are all binaries and the sdk repo has no exported libraries.
2. The go version declaration scaffolded into the go.mod file during init for the go plugins. This should only be bumped if a) any of the required libraries were bumped or b) if the scaffolded code itself makes use of new features in the new Go version. Bumping this version will alienate developers still using an older version of Go, so we need to consider the risk/reward tradeoff.

Regardless, this seems moot since it looks like controller-runtime will be using go1.17 for its next release, so point (a) applies.