Open DazWilkin opened 6 months ago
This seems like it could be an issue with either Kubebuilder's kustomize/v2 plugin, the controller-gen command, or controller-gen itself. I haven't had time, and likely won't have much time soon, to dig into this further.
I'm also not sure the motivation to upgrade your operator's scaffolding from the go/v3 to go/v4 format? This isn't needed and is not a trivial task for operator projects that have been heavily customized. Typically to do this the recommendation would be to scaffold a new go/v4 operator and transplant the business logic from the go/v3 operator to the appropriate place in the go/v4 operator.
My personal recommendation would be to stick with the go/v3 format and continue to update your dependencies as needed.
Thanks for taking the time to provide your feedback.
I periodically revisit the Operator SDK documentation to Upgrade SDK Version.
I'm paranoid that I'll end up with technical debt by not keeping the Operator current.
I suspect during the most recent upgrade, I noticed the go/v3 vs go/v4 docs.
Honestly, I've built this working Operator but the documentation's terms are still confusing to me. I don't understand what the 'go/vX plugin' even specifically refers to but, reading the documentation, it felt like something that I should be maintaining currency on too (so I did).
I did scaffold a new go/v4 operator and migrated the controllers etc. into it.
@DazWilkin Am I reading the below correctly?
I did scaffold a new go/v4 operator and migrated the controllers etc. into it.
That you resolved this issue and this can be closed?
Unfortunately, that's incorrect.
I scaffolded a new go/v4 operator, migrated the controllers etc. but that's where I'm observing the behavior.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle rotten /remove-lifecycle stale
Type of question
General operator-related help
Question
What did you do?
I'm attempting to migrate an existing (working) v3 Operator to v4 using Migration from go/v3 to go/v4
What did you expect to see?
The Operator worked outside a cluster. After Deployment to a cluster, I received a bunch of role errors and noticed that the
role.yaml
file was basic (unchanged):role.yaml
:I have 4 controllers and each has
kubebuilder:rbac
annotations|markers, e.g.:check_controller.go
Curiously, when I:
make manifests
per Generate CRD Manifests; or +make generate
per Generate Code & Artifacts in Kubebuilder, the file remains unchanged.Moreover (!) if I rename
role.yaml
and run either of the above commands, norole.yaml
is (re)created.And:
What did you see instead? Under which circumstances?
I expected
role.yaml
to be (re)generatedI checked the earlier (v3) Operator and it contains
rules
entries for each CRD for{resource}
,{resource}/finalizers
and{resource}/status
.I've manually edited
role.yaml
withapiGroups
,resources
andverbs
for the CRDs and the Operator WAI.Environment
Operator type:
/language go
Kubernetes cluster type:
GKE
$ operator-sdk version
operator-sdk version: "v1.34.1", commit: "edaed1e5057db0349568e0b02df3743051b54e68", kubernetes version: "1.28.0", go version: "go1.21.7", GOOS: "linux", GOARCH: "amd64"
$ go version
(if language is Go)go version go1.22.0 linux/amd64
$ kubectl version
Client Version: v1.29.3 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.29.3-gke.1093000
Additional context