Max allowed namespaces per helm-op from 1 (current) to n (proposed)

[ianmiell]

Apologies if this is a ramble, but I will endeavour to make this more coherent at a later date if this has legs.

I have been trying to get a model working whereby we have a 'global' flux that manages other fluxes in their own namespace that, in turn, deploy to another namespace from a separate git repo. It seems that this is logically impossible, as at present the helm-operator can either 'see' helmRelease items cluster-wide, or at a single namespace-specific level using allowNamespace. So I believe we are forced back to deploying separate fluxes one by one per namespace that we want to manage.

What would be good is if allowNamespace were able to take a subset of all all namespaces as 'allowed'. Then we could allocate a set of namespaces that a flux was responsible for.

What would be even better is if allowNamespace were itself dynamic, and taken from a git repo-managed config.

As a cherry on top, regexes would be even better, as we could then leverage naming standards, eg '^tenant-.*$' could be 'watched' in allowedNamespace(s).

[stefanprodan]

With this change #2334 you can create HRs in a namespace where helm-op runs and target other namespace.

[ianmiell]

So would the idea be that the 'global' flux would look at HRs in its own namespace (ie allowedNamespace would == namespace), but that these HRs could deploy fluxes/whatever to other namespaces?

[hiddeco]

Correct, see #2334