Select ProviderConfig via labels

[MisterMX]

What problem are you facing?

Crossplane managed resources currently support referencing a ProviderConfig via its object name through spec.providerConfigRef.name.

This requires the name to be known when creating the MR. However, this is not always the case. For example, if one creates an EKS cluster through a composition that also generates a new helm.crossplane.io/ProviderConfig, the name will have a dynamic hash appended as prefix. In this case one would have to wait for the composite resource and copy-paste the name before deploying resources on the cluster.

How could Crossplane help solve your problem?

Since one can add the composite labels to the ProviderConfig such as crossplane.io/claim-name and crossplane.io/claim-namespace one could select the respective provider config using this labels.

This way I could install a helm Release by referencing the config through a providerConfigSelector, i.e.

apiVersion: helm.crossplane.io/v1beta1
kind: Release
spec:
  forProvider:
    # ...
  providerConfigSelector:
    matchLabels:
       crossplane.io/claim-name: my-cluster
       crossplane.io/claim-namespace: my-project

[negz]

I think this is a duplicate of crossplane/crossplane#1699, though I'm tempted to keep this newer issue as it has a little more detail.

This is also loosely related to crossplane/crossplane#2255.

FWIW I'm a strong +1 on this and would be happy to see it implemented.

[muvaf]

@MisterMX would you be interested in contributing this? I think we can have another reference resolver specific to this and possibly have it placed in a chain before the default APISimpleReferenceResolver.

[MisterMX]

@muvaf yes, I can have a look at it, although my time is currently limited. But I am very interested in this feature.

[jbw976]

cool @MisterMX! if you don't get the time to do this soon, that's OK. There may be some other folks interested in taking on this somewhat scoped but beneficial feature.

If you start to work on it officially, please do assign yourself to it so we can coordinate :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AaronME]

We're running into this as well, given that we want to create both Kubernetes Clusters and things that launch to those kubernetes clusters from various Claims.

We currently make a best-effort attempt to match a generic environment parameter to the name of a cluster. And then we write every composite with a clusterOverride parameter, which tends to become the default.

With a selector, the environment could be patched as a label to generated ProviderConfigs and then targeted by claims with a similar label.