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
Best practices
How to implement a specific feature
Question
What did you do?
Our project needs to account for the presence/absence of various CRDs, and, depending upon the settings on our Operator's primary resource, the controller needs to handle those secondary resources. Examples include:
OpenShift Routes - they should only be created when Routes are available on the Cluster
CRDs/CRs that are defined and managed by other Operators using separate GVs
CRDs/CRs that are defined and managed by other Operators using the same GV as our Operator's primary resource
As far as what we did, we wrote functions similar to this response to a previous issue here for the first and second bullets, but, for the third, we used a check of the APIResources listed for the GV to see if that GVK was registered. Using those, we have the following in the init in our main.go:
Ideally, if someone ended up installing the CRDs that this Operator would have skipped loading support for here, the Operator could detect this and load the missing GVs into its scheme. Alternatively, if there's a way for them to always be loaded, but not lead to the Operator exiting when it's not able to watch for them at the start, I would be happy with that as well.
What did you see instead? Under which circumstances?
So far, it seems like by adding them to the scheme in our main.go's init, the Manager will end up trying to watch for them, leading to exits due to failed watches. Makes sense - the resources it's trying to look for are not supported yet. I'd prefer a solution that doesn't mandate a Pod restart when the new APIs become supported.
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.1", GitCommit:"05d83eff7e17160e679898a2a5cd6019ec252c49", GitTreeState:"clean", BuildDate:"2023-06-07T16:46:24Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"28+", GitVersion:"v1.28.13-eks-a737599", GitCommit:"9183cd02caedacf6a14583843262d53d6244fc4a", GitTreeState:"clean", BuildDate:"2024-08-26T21:27:49Z", GoVersion:"go1.22.5", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.26) and server (1.28) exceeds the supported minor version skew of +/-1
Additional context
The text was updated successfully, but these errors were encountered:
Type of question
Best practices
How to implement a specific feature
Question
What did you do?
Our project needs to account for the presence/absence of various CRDs, and, depending upon the settings on our Operator's primary resource, the controller needs to handle those secondary resources. Examples include:
As far as what we did, we wrote functions similar to this response to a previous issue here for the first and second bullets, but, for the third, we used a check of the
APIResources
listed for the GV to see if that GVK was registered. Using those, we have the following in theinit
in our main.go:In the
SetupWithManager
function for the controller, we have the following:What did you expect to see?
Ideally, if someone ended up installing the CRDs that this Operator would have skipped loading support for here, the Operator could detect this and load the missing GVs into its scheme. Alternatively, if there's a way for them to always be loaded, but not lead to the Operator exiting when it's not able to watch for them at the start, I would be happy with that as well.
What did you see instead? Under which circumstances?
So far, it seems like by adding them to the scheme in our main.go's
init
, the Manager will end up trying to watch for them, leading to exits due to failed watches. Makes sense - the resources it's trying to look for are not supported yet. I'd prefer a solution that doesn't mandate a Pod restart when the new APIs become supported.Environment
Operator type:
/language go
Kubernetes cluster type:
Vanilla and OpenShift
$ operator-sdk version
$ go version
(if language is Go)$ kubectl version
Additional context
The text was updated successfully, but these errors were encountered: