operator icon indicating copy to clipboard operation
operator copied to clipboard

Published 20 hours ago • verified publisher icon shipwright-io

[FEATURE] Upgrade operator-sdk to v1.31

Open adambkaplan opened this issue 2 years ago • 8 comments

Is there an existing feature request for this?

  • [X] 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:

adambkaplan avatar Aug 29 '23 16:08 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)

adambkaplan avatar Aug 29 '23 16:08 adambkaplan

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.

qu1queee avatar Sep 06 '23 13:09 qu1queee

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.

adambkaplan avatar Sep 08 '23 14:09 adambkaplan

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

qu1queee avatar Feb 08 '24 15:02 qu1queee

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

SaschaSchwarze0 avatar Mar 07 '24 15:03 SaschaSchwarze0

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 avatar Jun 04 '24 17:06 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.

adambkaplan avatar Dec 12 '24 15:12 adambkaplan

After further investigation of operator-sdk's current state, I do not think we should use it any more. Its upstream contributions/engagement have been reduced, and it is no longer necessary for building/releasing operators.

adambkaplan avatar Feb 20 '25 15:02 adambkaplan