bump operator-sdk version to v1.36.1

[lmilleri]

Followed instructions at https://sdk.operatorframework.io/docs/upgrading-sdk-version/v1.36.0/

[lmilleri]

@bpradipt PTAL

[bpradipt]

@lmilleri are there any golang module updates that needs to be done based on https://github.com/operator-framework/operator-sdk/blob/v1.36.1/go.mod ?

[lmilleri]

@lmilleri are there any golang module updates that needs to be done based on https://github.com/operator-framework/operator-sdk/blob/v1.36.1/go.mod ?

done

[bpradipt]

You'll need to use go 1.21 in your dev env to make this update.
The 1.36.1 sdk is still on 1.21. Although not strictly needed, but still it's good to use the same golang version as used with the sdk.

[lmilleri]

ok, will revert back to go 1.21

[lmilleri]

Not sure I should revert to go 1.21 though. When running go mod tidy the golang version is updated automatically to go 1.22.
This is because of the following dep:

go mod tidy -go=1.21 -compat=1.21
go: github.com/google/[email protected] requires [email protected], but 1.21 is requested

[bpradipt]

Hmm and do you know what is using pprof ? You will need to downgrade pprof otherwise.

[lmilleri]

pprof comes as an indirect dependency. The weird thing is that all the direct deps are aligned to https://github.com/operator-framework/operator-sdk/blob/v1.36.1/go.mod

[bpradipt]

Ok, one trick I use is to explicitly download a specific version of the offending dep. For example using the commit
before fa2c70bbbfe53334fe0fd4c80336583970707379 (https://github.com/google/pprof/commits/main/) should fix it imho.
But if you hit additional issues, then we'll have to stick to 1.22. Build and test should help uncover any potential issues.

[lmilleri]

It seems the trick works ok, Thank you

[mythi]

Go 1.21 is no longer maintained so it'd good to bump this to go 1.22.0 (note the new syntax that says "at least Go 1.22.0 toolchain is required"

[bpradipt]

/lgtm

[mythi]

We should gradually start moving away from the strict operator-sdk dependency. There's a deprecation announcement that states that controllers are free to move on after the initial scaffolding. What this means is here we can bump to more recent k8s/controller tools versions etc.

For trustee-operator, I'd suggest we add some new tests similar to what CC Operator added: test envtest against k8s vX, vX-1, and vX-2 control planes.

[bpradipt]

We should gradually start moving away from the strict operator-sdk dependency. There's a deprecation announcement that states that controllers are free to move on after the initial scaffolding. What this means is here we can bump to more recent k8s/controller tools versions etc.

My understanding is that the deprecation doesn't apply to usage of operator-sdk project and applies to only OpenShift shipped cli. We are not using it anyway for this project.

Ref: section titled: "What does this mean for the Operator SDK CNCF project?"

For trustee-operator, I'd suggest we add some new tests similar to what CC Operator added: test envtest against k8s vX, vX-1, and vX-2 control planes.

Agree..

[mythi]

We are not using it anyway for this project.

I see. This PR gave me the impression that we have a dependency to operator-sdk and that we follow versions dictated by what's in Openshift. To me, the gist of the announcements is that there's less coupling going forward.