Shane Starcher

Here is the PR I put in against this repo that I closed out - https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/1535/files

The current version used by the helm chart considers all states to be bad states. Do you have a recommended set of states that we can put in the helm...

I think that's a great idea, but with the implementation of `helmfile.d` where we have seperate charts and the possibility that users will have separate helmfiles for the same cluster...

I'm not following this statement ``` renaming of helmfile(s) in a helmfile.d will result in recreation of all the releases stored in the helmfile(s) ``` Why would renaming a helmfile...

In that case it would likely make sense for this to be a seperate command like `helmfile prune` vs a flag on `helmfile sync/charts`

The issue with leveraging the current `sync` is you now have a conflict with the selectors.

I see, what I imagined the design would be would, not to only remove what was in the helmfile previously, but to remove any resource that was not in the...

Yep, I 100% see value in this we just need to find a clean way to implement this.

ya, the additional state concerns me and I don't believe it's necissary. Yes, currently helmfile does not merge multiple files in helmfile.d together, but it could easily be implemented to...

ya, essentially we loop over all of the helmfiles. The function that does that could return the list of releases in the helmfile. And the overarching loop could accumulate that...