Custom annotations and labels for AWS family provider pod

[pierluigilenoci]

What problem are you facing?

When a provider in the AWS family is created, a further pod is created, but it is impossible to define specific labels or annotations for this pod.

How could an Official AWS Provider help solve your problem?

I want to specify labels/annotations for that pod.

[pierluigilenoci]

@turkenf, could you please take a look?

[turkenf]

Hi @pierluigilenoci,

• You can add the spec.skipDependencyResolution: true configuration to create the automatically created family provider yourself, please check here
• You can use DeploymentRuntimeConfig to add labels and annotations to the provider pods, please check here

For example, you can try the sample YAML file below to add labels to the pods of the s3 family provider.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-s3
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.47.1
  skipDependencyResolution: true
  runtimeConfigRef:
    name: my-runtime-config
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-family-aws
spec:
  package: xpkg.upbound.io/upbound/provider-family-aws:v0.47.1
  runtimeConfigRef:
    name: my-runtime-config
---
apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
  name: my-runtime-config
spec:
  deploymentTemplate:
    spec:
      selector: {}
      template:
        metadata:
          labels:
            my-label: my-value

[pierluigilenoci]

@turkenf thank you very much,
I will try what you suggest.

[turkenf]

You're welcome @pierluigilenoci

Have you had a chance to try it? If it works, we can close this issue.

[pierluigilenoci]

@turkenf still needs to.
We are still using a version of Crossplane that does not support DeploymentRuntimeConfigs.
We plan to switch to the new version soon and, therefore, be able to do the tests above.

[turkenf]

Then you can try with ControllerConfig, I did not try but metadata.labels or spec.metadata.labels might work.

[project-administrator]

Does it matter how I name the created provider-family-aws? Will other providers be able to communicate with it, because for me it gets created with this name by default: upbound-provider-family-aws.

If I already installed the other providers from that family, and after that apply the spec.skipDependencyResolution: true, will they undeploy the existing family provider instance to make sure there is no conflict between it and the newly configured provider? (because I can't have two provider instances with different names with the same spec.package)

[project-administrator]

Also, why does not the DeploymentRuntimeConfig apply to the upbound-provider-family-aws deployment even with the spec.selector: {}? Is there any reason for it not to inherit the DeploymentRuntimeConfig from the configured provider? ...

[pierluigilenoci]

As @project-administrator, I installed the family provider proactively as suggested here, with skipDependencyResolution set to true. However, the default family provider is still installed, pointing to the wrong DeploymentRuntimeConfig.

@turkenf Is there a way to have only the proactively installed one remaining?

[pierluigilenoci]

@turkenf I did some tests locally, and it works perfectly on a clean cluster.

If, instead, switching from the "automatic" to the "manual" situation, as happened to us, something dirty remains in Crossplane. Then, the Provider and ProviderRevision manifest of the "automatic" family provider remain in the cluster and are recreated even if manually deleted.

To try to reproduce the problem:

1. Install the providers WITHOUT family provider
2. Once the automatic family provider appears, try to install the family provider manually
3. Find a way to make the automatic family provider manifests disappear

[pierluigilenoci]

To follow up better, I created an issue #1452

[pierluigilenoci]

This is solved (also check #1452).