You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I need to report a bug in the operator-sdk generate kustomize manifests -q command. While I know the olm community is reworking the olm specification and the new roadmap, I'm not sure if the bundle will continue to be adopted. But I'd like to brief you on the matter at hand.
For the overall planning of the project, we will extract some of the possible public apis into a framework project, so that these api structures can be referenced in multiple operator projects. However, when I generated the bundle using operator-SDK in the operator project corresponding to this api, I found that it skipped updating the crd information in the csv.
I know it has a - apis field that specifies the directory where the api is located, but unless you use a relative path ../foo. Any other string value will look down based on the current project root directory, that is, the specified /root/foo/ directory.
In addition, when gvk is not found, the warning log does not show the gvk name, but I see that the source code has a corresponding logic.
My current practice is to download the corresponding package into the project directory through vendor mode, and then specify the corresponding directory.
What did you expect to see?
I want to operator-sdk generate kustomize manifests --apis-dir to support parsing go modules, like the paths parameter for controller-gen, so that the corresponding api directory is automatically found in the go environment.
What did you see instead? Under which circumstances?
operator-sdk generate kustomize manifests -q
WARN[0000] Skipping definitions parsing for API {}: Go type not found
The corresponding gvk is not displayed in the warning information. But the source code has its logic
I know the olm community is debating the future of V1, and we'll be switching to helm based management in the coming weeks. So this question may not be as important to us anymore, but it's still helpful to other people who are using it. Or in the future, the olm community may remove this functionality.
The text was updated successfully, but these errors were encountered:
Bug Report
What did you do?
I need to report a bug in the
operator-sdk generate kustomize manifests -q
command. While I know the olm community is reworking the olm specification and the new roadmap, I'm not sure if the bundle will continue to be adopted. But I'd like to brief you on the matter at hand.For the overall planning of the project, we will extract some of the possible public apis into a framework project, so that these api structures can be referenced in multiple operator projects. However, when I generated the bundle using operator-SDK in the operator project corresponding to this api, I found that it skipped updating the crd information in the csv.
I know it has a - apis field that specifies the directory where the api is located, but unless you use a relative path
../foo
. Any other string value will look down based on the current project root directory, that is, the specified/root/foo/
directory.In addition, when gvk is not found, the warning log does not show the gvk name, but I see that the source code has a corresponding logic.
My current practice is to download the corresponding package into the project directory through vendor mode, and then specify the corresponding directory.
What did you expect to see?
I want to
operator-sdk generate kustomize manifests --apis-dir
to support parsing go modules, like thepaths
parameter forcontroller-gen
, so that the corresponding api directory is automatically found in the go environment.What did you see instead? Under which circumstances?
The corresponding gvk is not displayed in the warning information. But the source code has its logic
operator-sdk/internal/generate/clusterserviceversion/bases/definitions/definitions.go
Lines 93 to 96 in 5ddea3c
When I randomly specify an actual absolute directory through the -API, it will be concatenated based on the current project root directory
Environment
Operator type:
1.22
or1.23
Kubernetes cluster type:
kind
$ operator-sdk version
operator-sdk version: "v1.35.0", commit: "e95abdbd5ccb7ca0fd586e0c6f578e491b0a025b", kubernetes version: "1.28.0", go version: "go1.21.11", GOOS: "darwin", GOARCH: "arm64"
$ go version
(if language is Go)go version go1.23.0 darwin/arm64
$ kubectl version
Client Version: v1.30.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Possible Solution
Additional context
I know the olm community is debating the future of V1, and we'll be switching to helm based management in the coming weeks. So this question may not be as important to us anymore, but it's still helpful to other people who are using it. Or in the future, the olm community may remove this functionality.
The text was updated successfully, but these errors were encountered: