[supriyo-biswas]

How do you handle cleanups and hooks? The best way to do helm, at least for me, seems to be about limiting its use to simple templating use cases; if you end up needing an if, you've probably done something terribly wrong.

[cassianoleal]

That's my main gripe with Helm.

For the simple use case you're describing, Helm is not required. Plenty of other solutions around.

For use cases where it starts getting useful, we both agree that something has gone terribly wrong.

I still don't know why Helm exists. It's a solution that created lots of problems that didn't exist.

[antonvs]

My personal theory is that Helm may be ok for distributing a pre-packaged solution to other people. Then people mistook it for a tool that should be used in-house to deploy a company’s own systems, where it makes much less sense.

[a456463]

It makes absolute sense. You can use no variables and still deploy helm chart. It is a directory of plain old yaml objects. And add customization when you need as you evolve. Good luck doing that with kustomize.

[antonvs]

> And add customization when you need as you evolve.

Using one of the most horrible templating languages since ASP. Helm is what happens when a devops team decides to yolo into software development.

What's the issue with kustomize? It works well for us.

[arkeros]

You can rely purely on kubectl with something like:

cat manifests.yaml | kubectl apply -f - --server-side --field-manager "$FIELD_MANAGER" --prune --applyset "$APPLYSET" --namespace "$NAMESPACE"

[srcreigh]

Seems to be a case of the XY problem. What do you need cleanups and hooks for?

[supriyo-biswas]

Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources.

Hooks: I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster (at places I've worked, the CI cluster and K8s cluster were completely separate).

[vbezhenar]

Regarding cleanups: I'm using flux CD with kustomize. It tracks resources that it created. If I delete manifest from my repository, flux will delete resources that were created from these manifests. For me that's pretty much the ideal workflow.

Regarding hooks: I don't know. All applications that I've used, implemented migrations internally (it's usually Java with Flyway), so I don't need to think about it. One possible approach could be to use flux CD with Job definition. I think that Flux will re-create Job when it changes. So if you change image tag, it'll re-create Job and it'll trigger Pod execution. But I didn't try this approach, so not sure if that would work for you.

[cassianoleal]

> Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources.

    kubectl delete -f <manifests.yaml>

    kubectl delete -k <kustomization_directory>

> I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster

A Job feels like a good fit for this. CI deployes the Job without connecting to DB, Job runs migrations using the same connectivity as the application.

[johntash]

> apply my database migrations and populate the database with static datasets before I deploy my application

You could a) have the app acquire a lock in the db and do its own migrations, or b) create a k8s job that runs the migration tool, but make sure the app waits for the schema to be updated or at least won't do anything bad.

[0xbadcafebee]

There are a multitude of cases of operations which need to be performed before and after specific actions in K8s. It depends on the resource, operator, operational changes, state, bugs, order of operations, and more.

[a456463]

This is a BS claim with no proof. This is the strength of helm.