Why do AWS and Upbound AWS Providers create a default provider config?

[danielloader]

The creation of a default provider config in addition to the aws-provider-config is conflicting when trying to install the kubernetes provider in addition to the AWS/Upbound AWS providers.

Is this intentional?

Thanks

[danielloader]

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?

[csantanapr]

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 default is because if your testing or developing crossplane compositions you can ignore the ProviderConfig and it will default to default
The second one we create is default name "aws-provider-config" but you can set it in values.yaml is for the installation to be compatible with the examples from this git repo https://github.com/awslabs/crossplane-on-eks/blob/main/examples/upbound-aws-provider/composite-resources/s3-irsa/s3-irsa.yaml#L7

I'm thinking if you want to create a providerConfig and not deploy default duplicate we could add a variable in values.yaml

[danielloader]

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 serviceAccountTemplate block completely in favour of nominating the service account name in the deploymentTemplate and CPU use dropped from 3 CPU cores to 200m.

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.

[csantanapr]

Hi @danielloader I fixed the issue on the case of always creating the default providerConfig for the aws-upbound providers here 038d85d#diff-5c5759e746204767a274460877bc4a11f41df759044d34cb8f57b72320978c76

You can disable it like this

providerConfig:
  enabled: true
  default: false

it would only create 1 providerConfig with the name that you specify in providerConfig.metadata.name

[csantanapr]

Can you share your changes here on how you deploymentTemplate looks like?

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?