Move operator-sdk to v1.33.0

[ramperher]

Consequently, also bump kustomize version to the version used by operator-sdk v1.33.0, as shown in this PR

[ramperher]

check dallas ocp-4.13-vanilla example-cnf

[tkrishtop]

Hi @ramperher I think we need 3.8.7 for the kustomized as well, when moving to operator-sdk 1.33.0. I checked fast, it seems like to be the case already, so looks good

[ramperher]

Hi @ramperher I think we need 3.8.7 for the kustomized as well, when moving to operator-sdk 1.33.0. I checked fast, it seems like to be the case already, so looks good

I can change that, curiously we have one operator using 3.8.7 but the others using 3.5.x. I can bump that too

[ramperher]

@tkrishtop , in fact, I've found some interesting info related to kustomize in the v1.33.0 release.

If you go to the release notes, it highlights the following change:

Breaking change: (kustomize/v2-alpha): kustomize/v2 is now stable and is the default version used in the plugin chain when using go/v4, ansible/v1, helm/v1, and hybrid/v1-alpha plugins. (operator-framework/operator-sdk#6613)

By accessing to that PR, we can see the following info:

(kustomize/v2): kustomize/v2 is now stable and is the default version used in the plugin chain when using go/v4, ansible/v1, helm/v1, and hybrid/v1-alpha plugins
...
fixes operator-framework/operator-sdk#4975 (kustomize/v2 plugin uses v5.1.1)

So, my impression is that operator-sdk v1.33.0 then supports kustomize v5.1.1? Should we move to that version?

[tonyskapunk]

@tkrishtop , in fact, I've found some interesting info related to kustomize in the v1.33.0 release.

If you go to the release notes, it highlights the following change:

Breaking change: (kustomize/v2-alpha): kustomize/v2 is now stable and is the default version used in the plugin chain when using go/v4, ansible/v1, helm/v1, and hybrid/v1-alpha plugins. (operator-framework/operator-sdk#6613)

By accessing to that PR, we can see the following info:

(kustomize/v2): kustomize/v2 is now stable and is the default version used in the plugin chain when using go/v4, ansible/v1, helm/v1, and hybrid/v1-alpha plugins ... fixes operator-framework/operator-sdk#4975 (kustomize/v2 plugin uses v5.1.1)

So, my impression is that operator-sdk v1.33.0 then supports kustomize v5.1.1? Should we move to that version?

You want to look at the upgrading doc for v1.33.0 instead https://sdk.operatorframework.io/docs/upgrading-sdk-version/v1.33.0/

There is also a reference to kustomizev2, that explains that in some cases is should be used v4 and in others v5 of kustomize. The references made in there are for v5.0.0, but if you create an operator (golang based) from scratch, you will see it is using v5.0.1. So most likely you want to upgrade to v5.0.1 and not v5.1.1

❯ operator-sdk version
operator-sdk version: "v1.33.0", commit: "542966812906456a8d67cf7284fc6410b104e118", kubernetes version: "1.27.0", go version: "go1.21.5", GOOS: "linux", GOARCH: "amd64"

❯ operator-sdk init --domain example.com --repo example.com 2>/dev/null 2>&1 && grep ^KUSTOMIZE_VERSION Makefile
Writing kustomize manifests for you to edit...
Writing scaffold for you to edit...
Get controller runtime:
$ go get sigs.k8s.io/controller-runtime@v0.15.0
Update dependencies:
$ go mod tidy
Next: define a resource with:
$ operator-sdk create api
KUSTOMIZE_VERSION ?= v5.0.1

[ramperher]

@tkrishtop , in fact, I've found some interesting info related to kustomize in the v1.33.0 release.
If you go to the release notes, it highlights the following change:
Breaking change: (kustomize/v2-alpha): kustomize/v2 is now stable and is the default version used in the plugin chain when using go/v4, ansible/v1, helm/v1, and hybrid/v1-alpha plugins. (operator-framework/operator-sdk#6613)
By accessing to that PR, we can see the following info:
(kustomize/v2): kustomize/v2 is now stable and is the default version used in the plugin chain when using go/v4, ansible/v1, helm/v1, and hybrid/v1-alpha plugins ... fixes operator-framework/operator-sdk#4975 (kustomize/v2 plugin uses v5.1.1)
So, my impression is that operator-sdk v1.33.0 then supports kustomize v5.1.1? Should we move to that version?

You want to look at the upgrading doc for v1.33.0 instead https://sdk.operatorframework.io/docs/upgrading-sdk-version/v1.33.0/

There is also a reference to kustomizev2, that explains that in some cases is should be used v4 and in others v5 of kustomize. The references made in there are for v5.0.0, but if you create an operator (golang based) from scratch, you will see it is using v5.0.1. So most likely you want to upgrade to v5.0.1 and not v5.1.1

❯ operator-sdk version
operator-sdk version: "v1.33.0", commit: "542966812906456a8d67cf7284fc6410b104e118", kubernetes version: "1.27.0", go version: "go1.21.5", GOOS: "linux", GOARCH: "amd64"

❯ operator-sdk init --domain example.com --repo example.com 2>/dev/null 2>&1 && grep ^KUSTOMIZE_VERSION Makefile
Writing kustomize manifests for you to edit...
Writing scaffold for you to edit...
Get controller runtime:
$ go get sigs.k8s.io/controller-runtime@v0.15.0
Update dependencies:
$ go mod tidy
Next: define a resource with:
$ operator-sdk create api
KUSTOMIZE_VERSION ?= v5.0.1

Thanks @tonyskapunk for all the information, as usual :) it makes sense to me, so yes, let's do that

[ramperher]

check dallas ocp-4.13-vanilla example-cnf

[ramperher]

check dallas ocp-4.13-vanilla example-cnf

[dcibot]

• FAILURE https://www.distributed-ci.io/jobs/45ebc7f7-6019-411f-a49b-40ded33cf8ae/jobStates
• NEW https://www.distributed-ci.io/jobs/e9a071fb-a988-4ced-94ce-ba2411f893f3/jobStates
  from Move operator-sdk to v1.33.0 #33

[ramperher]

Correct job tracking this installation is this one, and for the moment is working, it's in preflight testing: https://www.distributed-ci.io/jobs/a9decd42-0206-4a73-920c-e4c025a78996/jobStates?sort=date

[dcibot]

• SUCCESS https://www.distributed-ci.io/jobs/a9decd42-0206-4a73-920c-e4c025a78996/jobStates
  from Move operator-sdk to v1.33.0 #33