Closed Nicolas-Duboc-IBM closed 6 months ago
Changes from PR #6626 are a proposal to fix this issue.
@Nicolas-Duboc-IBM Could you elaborate on what is the reason for having a nested spec defined in a separate package? Wondering on what is the necessity to have a different package and not have it in one.
Starting from an existing operator managing a single Kind, we added a second Kind with a very similar structure and same management code. During this refactoring we moved all the shared types into a "common" package and the top-level types in their own packages also.
After second thought, I realize that we could have kept all the types in the same package and simply splitted into multiple go files. Actually I just tested moving back all the types in a single package and it works also. operator-sdk
then generates the correct CSV with all the expected markers.
Then perhaps this problem could be fixed simply with more documentation about this limitation.
Actually it seems that multiple go packages are required to manage kinds in different API group. Because the +groupName
annotation is put on go packages.
@Nicolas-Duboc-IBM that's right, this is the expected behaviour with markers in controller-tools. This is because the marker on the parent has no way to discover the fields in the child struct. Would you be open to adding documentation on this?
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
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen
.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Exclude this issue from closing again by commenting /lifecycle frozen
.
/close
@openshift-bot: Closing this issue.
Bug Report
What did you do?
In a Go operator project, spread the types of the API in multiple go packages:
A sample project is available at https://github.com/Nicolas-Duboc-IBM/operatorsdk-multipackage-sample
File operatorsdk-multipackage-sample/api/v1alpha1/example_types.go :
File operatorsdk-multipackage-sample/api/common/common.go :
What did you expect to see?
After running
operator-sdk generate kustomize manifests
, or more typicallymake bundle
, I expected to find an entry forpath: options.hidden1
with theurn:alm:descriptor:com.tectonic.ui:hidden
property in the generated CSV in fileconfig/manifests/bases/operator-sdk-defect.clusterserviceversion.yaml
.What did you see instead? Under which circumstances?
Only the fields of the top-level types are included in the CSV. The fields of lower-level types are not considered.
File config/manifests/bases/operator-sdk-defect.clusterserviceversion.yaml :
There should be an entry for
options.hidden1
:Environment
Operator type:
/language go
Possible Solution
Additional context