-
Notifications
You must be signed in to change notification settings - Fork 76
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
Required import to avoid no auth provider available #26
Conversation
``` ERROR controller-runtime.manager Failed to get API Group-Resources {"error": "no Auth Provider found for name \"gcp\""} ``` Signed-off-by: salaboy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also found this related upstream client-go issue: kubernetes/client-go#839
I'm not sure why we don't see this in core crossplane itself, I don't see it importing this same package in the main crossplane entry point: https://github.com/crossplane/crossplane/blob/master/cmd/crossplane/main.go
Or in providers like provider-aws: https://github.com/crossplane/provider-aws/blob/master/cmd/provider/main.go
Anyone have insight into why it's not needed there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbw976 @salaboy this same behavior could happen with Crossplane or any of the providers, but it only happens when running out of cluster and requiring "auth helpers" from a given cloud provider. For instance, if I have a GKE cluster that gives me a kubeconfig that specified to use gcloud to authenticate, we will not behave properly. This is typically not the setting that Crossplane or the providers are run in, but it can be helpful for developing locally against a remote cluster. I am fairly indifferent to whether we add it here by default or not.
Ah, thanks for that clarification @hasheddan, that helps me understand this scenario further. I agree that a typical provider wouldn't be executed in this type of setup, where it is running outside of its control plane that is hosted in a cloud provider. In this template repo, I'd lean towards optimizing for the common scenario, given this comment, this comment and this PR, meaning I don't think this import is needed by default.
What are your thoughts on including this @salaboy? Happy to hear your opinion too :) |
@jbw976 I think it makes a lot of sense to not include it in the code itself, as that is not needed there for the provider final version running inside a cluster. But it should be mentioned in the https://github.com/crossplane/provider-template/blob/master/README.md inside the Developing section. |
Closing some very old PRs. :) |
When trying to run the template project with make run, you hit this issue
Related: hashicorp/terraform-provider-kubernetes-alpha#46
This import fixes the problem:
Which makes kind of sense..