Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

+operator-sdk:csv:customresourcedefinitions:order does not change order in bundle #6771

Open
mateusoliveira43 opened this issue Jun 11, 2024 · 2 comments
Labels
language/go Issue is related to a Go operator project lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@mateusoliveira43
Copy link

Bug Report

What did you do?

Created new structure with operator-sdk version v1.34.2. I ran the following commands:

mkdir 1_34_2
cd 1_34_2
operator-sdk init --project-name=oadp-operator --repo=github.com/openshift/oadp-operator --domain=openshift.io
# manually changed CONTROLLER_TOOLS_VERSION to v0.14.0 in Makefile because I am using go1.22.3 
operator-sdk create api --group oadp --version v1alpha1 --kind DataProtectionApplication --resource --controller
operator-sdk create api --group oadp --version v1alpha1 --kind CloudStorage --resource --controller
make bundle
# fill inputs with "test"

Then checked that in 1_34_2/config/manifests/bases/oadp-operator.clusterserviceversion.yaml and 1_34_2/bundle/manifests/oadp-operator.clusterserviceversion.yaml files, CloudStorage appears first then DataProtectionApplication (sorted alphabetically by default?) in spec.customresourcedefinitions.owned list.

Then, I manually added // +operator-sdk:csv:customresourcedefinitions:order=1 in 1_34_2/api/v1alpha1/dataprotectionapplication_types.go and ran make bunble again. In 1_34_2/config/manifests/bases/oadp-operator.clusterserviceversion.yaml the order changes, and DataProtectionApplication appears first, but not in 1_34_2/bundle/manifests/oadp-operator.clusterserviceversion.yaml.

What did you expect to see?

CRDs appearing in the order I desire in bundle CSV file.

What did you see instead? Under which circumstances?

CRDs appearing sorted alphabetically in bundle CSV file.

Environment

Operator type:

/language go

Kubernetes cluster type:

Not releated

$ operator-sdk version

operator-sdk version: "v1.34.2", commit: "81dd3cb24b8744de03d312c1ba23bfc617044005", kubernetes version: "1.28.0", go version: "go1.21.10", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

go version go1.22.3 linux/amd64

$ kubectl version

Not related

Possible Solution

Not at the moment. (Manual workaround is changing order after running make bundle)

Additional context

This is important in my opinion, because UIs (like https://operatorhub.io/ and OpenShift) use the order the CRD appear in spec.customresourcedefinitions.owned list to render them. This way, developers can use the order to show priority of CRDs to users.

@openshift-ci openshift-ci bot added the language/go Issue is related to a Go operator project label Jun 11, 2024
@openshift-bot
Copy link

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

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 10, 2024
@mateusoliveira43
Copy link
Author

/lifecycle frozen

@openshift-ci openshift-ci bot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language/go Issue is related to a Go operator project lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

2 participants