[FEATURE] Upgrade operator-sdk to v1.31

[adambkaplan]

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

operator-sdk is a critical part of our build and release process. It is significantly out of date and needs to be upgraded. Unfortunately, there are several manual steps involved since operator-sdk assumes that your project has a Makefile with specific structures and attributes.

Describe the solution that you would like.

Upgrade the project to operator-sdk v1.31, iterating through each upgrade step along the way (starting with 1.18).

See https://sdk.operatorframework.io/docs/upgrading-sdk-version/

Describe alternatives you have considered.

• Stay at operator-sdk v1.17 - our tech debt continues to accumulate with compounding interest.
• Drop operator-sdk - we would have to roll our own operator build/release process.

Anything else?

Links to each upgrade step - note that we should only follow the upgrade steps for go-based operators. Changes related to Helm and Ansible-based operators do not apply:

• operator-sdk v1.18.0: Completed by Update operator-sdk to v1.18 #164
• operator-sdk v1.19.0
• operator-sdk v1.20.0
• operator-sdk v1.21.0
• operator-sdk v1.22.0
• operator-sdk v1.23.0
• operator-sdk v1.24.0
• operator-sdk v1.25.0
• operator-sdk v1.26.0
• operator-sdk v1.27.0
• operator-sdk v1.28.0
• operator-sdk v1.29.0
• operator-sdk v1.30.0
• operator-sdk v1.31.0

[adambkaplan]

A note on implementation - this can/should be split into multiple pull requests if it makes sense. I recommend that each version increase have a separate commit with corresponding CI checks run (so we ensure we don't break anything along the way)

[qu1queee]

From refinement, we did drop the operator-sdk from the Build project. @adambkaplan we think you might have more context to decide if any of the alternatives would work.

[adambkaplan]

Dropping operator-sdk from Build made a lot of sense, and that decision shouldn't change.

For this project, the operator-sdk provides a CLI with the features needed to build, test, and deploy the operator via OLM. The actual controller code runs with the controller-runtime library - there is no specific dependency on operator-framework libraries any more.

[qu1queee]

From Refinement, this still in Progress but subject to change, @adambkaplan to provide an update later.

[SaschaSchwarze0]

@adambkaplan is this a blocker for v0.13 or something we want to do in 0.13?

[adambkaplan]

Update: this should wait until after v0.13.0 lands for the operator. There are a lot of fundamental changes in operator-sdk that will warrant a significant refactor of the operator itself.

[adambkaplan]

With Operator Lifecycle Manager v1, this feature may be completely obsolete. Moving this to the backlog - we need to determine if operator-sdk is still a relevant/useful tool for OLM v1.