-
Notifications
You must be signed in to change notification settings - Fork 3
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
Why do AWS and Upbound AWS Providers create a default provider config? #5
Comments
Okay turns out provider configs are namespaced to providers! TIL. Leave this issue here in case anyone questions it in future. In which case I'll invert my question, why do the AWS/AWS Upbound providers create a default and a named providerConfig? |
Thank you @danielloader for opening this issue and your question. You can choose to not create any providerConfig, this is what you probably do when you go into production, because you would create many different providerConfigs each one with a unique access depending on tenant, or access limitations you can to provide providerConfig:
enabled: false If your question is when is enable 2 duplicate providerConfigs are created one of them I'm thinking if you want to create a providerConfig and not deploy |
Thanks for the answer! In addition to this question, a slightly different one: crossplane/crossplane#5458 (comment) Using this helm chart to deploy aws-providers I've found that I experienced a race condition where all the sub-providers of the aws family were fighting for object ownership of a service account if that service account was shared between the family members. I forked the chart and removed the You might be able to reproduce this locally by describing the shared service account on a loop and confirming the owner references are in flux. |
Hi @danielloader I fixed the issue on the case of always creating the You can disable it like this providerConfig:
enabled: true
default: false it would only create 1 providerConfig with the name that you specify in |
Can you share your changes here on how you Would this mean every provider will point to unique named service account? What about creating a unique DeploymentRuntimeConfig per provider, and the template on each deploymentruntimeconfig specify a unique service account name? |
The creation of a
default
provider config in addition to theaws-provider-config
is conflicting when trying to install the kubernetes provider in addition to the AWS/Upbound AWS providers.Is this intentional?
Thanks
The text was updated successfully, but these errors were encountered: