Namespace scoped Release object (helm.m.crossplane.io) does not support namespace field in spec.forProvider.chart.pullSecretRef

[IlliaZhahlouTR]

What happened?

Release object does not support namespace configuration in spec.forProvider.chart.pullSecretRef. Provider is looking for a secret in the same namespace where Release object is being created. It forces to create/duplicate the secret which can already be present in a cluster.

How can we reproduce it?

Could be reproduced in any cluster when using Release object of helm.m.crossplane.io API group

What environment did it happen in?

• Crossplane version: 2.0.2
• Cloud provider or hardware configuration: AWS
• Kubernetes version (use kubectl version): Client Version: v1.31.10, Server Version: v1.31.10-eks-931bdca
• Kubernetes distribution (e.g. Tectonic, GKE, OpenShift): EKS, in general any k8s cluster
• OS (e.g. from /etc/os-release): not relevant
• Kernel (e.g. uname -a): not relevant

[bobh66]

I believe this is by design - namespaced Releases are (mostly) restricted to their namespace. The Cluster-scoped Release should have access to all namespaces.

[IlliaZhahlouTR]

I believe this is by design - namespaced Releases are (mostly) restricted to their namespace. The Cluster-scoped Release should have access to all namespaces.

Based on the crossplane documentation:
"New provider releases will support both namespaced and cluster scoped MRs. Crossplane v2 considers cluster scoped MRs a legacy feature. Crossplane will deprecate and remove cluster scoped MRs at a future date."

Means that cluster scoped resources will be removed form providers soon or late.
Deploying crossplane Release object into specific namespace should not mean that you can not use credential secrets from other namespaces.
There is another similar issue: #298

[bobh66]

Yeah I'm not thrilled with that wording (cc @negz) for just this reason. There are currently no plans to remove any cluster-scoped MRs and personally I believe the additional work and potential for disruption caused by removing them far outweighs any benefits of having less code to maintain. I'm going to propose we reword or remove that statement to avoid confusion.

#298 is related to the target namespace where the helm release is being installed. Since the ProviderConfig could be pointing at a remote cluster the target namespace cannot be restricted to the local Release namespace.

[IlliaZhahlouTR]

Yeah I'm not thrilled with that wording (cc @negz) for just this reason. There are currently no plans to remove any cluster-scoped MRs and personally I believe the additional work and potential for disruption caused by removing them far outweighs any benefits of having less code to maintain. I'm going to propose we reword or remove that statement to avoid confusion.

#298 is related to the target namespace where the helm release is being installed. Since the ProviderConfig could be pointing at a remote cluster the target namespace cannot be restricted to the local Release namespace.

Thanks for a quick reply.
My point regarding #298 was that namespace field was removed by mistake. I think it applies to spec.forProvider.chart.pullSecretRef as well and removing the namespace field just limits end user experience. Adding spec.forProvider.chart.pullSecretRef.namespace as optional field could help to avoid issues for many people when switching from "helm.crossplane.io" to "helm.m.crossplane.io".

[ilia-medvedev-codefresh]

I can say this is a definite blocker for me at least in switching to the namespaced MRs for this provider. Helm releases are more often then not deployed to remote clusters and the namespace in the target cluster has nothing to do with the namespace the release object is created on in the Crossplane control plane. I'd be willing to help implement whatever is needed to add this support, though it seems like #298 has got it working.

Can someone from the provider maintainers confirm adding this support is on the agenda? If this is the case I can switch to the namespaced MRs and use a development version of the provider in the meantime