HelmChart sourceRef lacks namespace

[vlasov-y]

If I specify chart via HelmRelease's .spec.chart.spec.sourceRef it has a namespace field, but If I want to create a HelmChart object myself, it does not have such field in the schema. Can it be added? If yes, I will try to do it and prepare a PR.

[matheuscscp]

Think about it: If the actual HelmChart CRD doesn't have the field, have you questioned yourself "what the heck does helm-controller do with the field from the template? Because if the actual field does not exist, then something is definitely not well explained". Well, I did, and found out the obvious, hc.spec.sourceRef.namespace is not specified because it doesn't exist, and found out also the non-obvious, hr.spec.chart.spec.sourceRef.namespace is used to specify hc.metadata.namespace.

Conclusion: The field you use in HelmRelease is not what you expected anyway and hence cannot be used as argument for this request.

Furthermore, object references between namespaced objects in Kubernetes are usually local, because the namespace is the security boundary. The fact that we have some cross-namespace references is something we regret and are trying to move away from.

Also, OCI artifacts are the future of packaged configuration, please take a look at using HelmRelease with OCIRepository:

• https://fluxcd.io/flux/components/helm/helmreleases/#ocirepository-reference-example
• https://helm.sh/docs/topics/registries/

[vlasov-y]

@matheuscscp

have you questioned yourself "what the heck does helm-controller do with the field from the template?

It is obvious, it selects a namespace for helm chart object. That is a behavior I expected and the one I got.

Also, OCI artifacts are the future of packaged configuration, please take a look at using HelmRelease with OCIRepository:

I already use it everywhere it is possible, but unfortunately, many helm repo's have not migrated to OCI.

Conclusion: The field you use in HelmRelease is not what you expected anyway and hence cannot be used as argument for this request.

I disagree. Let' me show you:

1. Can Kustomization create resource in different namespace? - Yes, it even has .spec.targetNamespace field.
2. Can HelmRelease create resources in different namespace? - Yes, that is not a problem
3. Can Kustomization use GitRepository from a different namespace? - Yes, it has .spec.sourceRef.namespace

The question I have asked myself is "Why they have missed namespace field in HelmChart CRD?"
And another one bad question: "Why flux-cli always looks at flux-system if I expect it to look at the namespace selected in the kubeconfig?"

Suggestion: Add namespace field to HelmChart CRD in order to make it able to use HelmRepository from different namespace. By default, if not set, it will use current namespace, which is a default behavior, so no issues here.

Another option is to add Cluster* (ClusterHelmRepository, ClusterGitRepository, etc.). In this case, removing namespace field from CRDs is acceptable.

[matheuscscp]

It is obvious, it selects a namespace for helm chart object. That is a behavior I expected and the one I got.

Then what you're looking for is hc.metadata.namespace and hr.spec.chartRef.namespace. You can create the HelmChart on the same namespace of its source and reference it from a HelmRelease in another namespace. That is 100% equivalent to using hr.spec.chart the way you mentioned.

[vlasov-y]

It is obvious, it selects a namespace for helm chart object. That is a behavior I expected and the one I got.

Then what you're looking for is hc.metadata.namespace and hr.spec.chartRef.namespace. You can create the HelmChart on the same namespace of its source and reference it from a HelmRelease in another namespace. That is 100% equivalent to using hr.spec.chart the way you mentioned.

And I would go that way with pleasure, but I have namespace set in kustomization.yaml and it overrides the namespace I can hardcode in HelmChart resource. That is why extra namespace field is required. And I do not want to create HelmChart and HelmRelease separately.