Support cross namespace references in DependsOn field about helm-controller

[xunholy]

helm-controller/controllers/helmrelease_controller.go

Line 430 in 9b5db2d

Namespace: hr.GetNamespace(),

This should be configurable, or at least if I specify <namespace>/<chart-name> syntax it should accept the prefix as the namespace - it could default to the namespace of the helmRelease.

[hiddeco]

This should be configurable I would like this to be configurable, or at least if I specify <namespace>/<chart-name> syntax it should would accept the prefix as the namespace - it could default to the namespace of the helmRelease.

We deliberately choose to not support this in the initial version, as we were still working out the details around RBAC and crossing namespaces in particular. This is also one of the reasons it is no longer possible to refer to ConfigMap and Secret resources in another namespaces for ValuesFrom items.

I can see the usefulness of being able to refer to a HelmRelease in another namespace, especially because otherwise it would not be possible to for example refer to a Linkerd deployment released via Helm. It also would not result in any data leaks, which is the reason we eliminated support for cross namespace ValuesFrom references.

[xunholy]

@hiddeco I figured the secrets being used as ValuesFrom other namespaces was a realistic constraint seeing as the workload should be self-contained in the sense all of its dependencies are within the same namespace scope.

For DependsOn I can't see any real issues in terms of RBAC for chart dependencies - This is more for cluster tooling that gets deployed either by my fleet or cluster repo as I'll have things like cert-manager which deploys with service monitors which means I have a dependency on my observability charts like prometheus-operator however, I wouldn't deploy these into a singular scoped namespace as they have individual RBAC models of their own in a multi-tenant cluster.

[xunholy]

@stefanprodan @hiddeco given the use case and how this is likely to be a valuable feature is it on the foreseeable roadmap? I'm also willing to assist where possible to help and/or contribute any required functionality or be involved in any design discussions that may need to take place.

[hiddeco]

It is on our to-do list, and the option that has crossed our minds thus far (label selectors as a replacement for specific resource selectors) will be a breaking API change.

We can however not give a timeframe on design finalization or actual implementation at this point, as the pile of things with a short-term priority in terms of issues, design questions, and UX improvements across the GitOps Toolkit is as you can imagine still pretty high. We also prioritize Flux v1 feature parity issues at the moment, and none of the above (or even the feature as it stands right now) is available in the v1 of Flux and the Helm Operator.

In addition to all of this it comes with a couple of technical questions / challenges, for example the changes that would be required to the algorithm (Tarjan's SCC) we use for sorting.