Shane Starcher

ahh namespaced tillers do make that more difficult. That would certainly have to go into the calculation for the rollup.

Sounds great

So are we to assume that `tiller` only has access to the namespace it's in? Tiller can easily control all namespaces, just the one it's in, or x specific namespaces...

Could this not be solved by `environments`? So one issue I have with my current use of globals is that it does not play nice with something like Atlantis. If...

I don't have that issue due to separating out our terraform modules. I do the following. * Each module is in it's own github repo and has tests on commit...

I would lean toward recommending using templating and environments. * Globals go in the environment * Use a gotmpl to define it and insert it into your resource

For helm 3 it would need secret access to any namespace that has a helm chart running in it as helm stores data as secrets by default in Helm 3.

If the user used a different storage mechanism than a secret we could move to that, but if it's stored in a secret we are limited to needing access.

It will do it on each call to `/metrics` you can set it up to do this in the background and to cache the results if you use https://github.com/sstarcher/helm-exporter/blob/master/main.go#L50

It could certainly help people who have large clusters