Oneshot jobs

[mumoshu]

I'm a bit hesitant to propose this but how about supporting oneshot jobs in helmfile?

An oneshot job can be either a K8S job or a pod created via helm upgrade --install to accomplish a job like db migration, enqueueing a large job to a kind of workflow system, etc.

As of today, we have to resort a variant of kubectl run --image $img to run an oneshot job, even in a situation that our regular app are managed by helm and shared the image, envvars with oneshot jobs.

AFAIK, there's no such tool to support this use-case. And supporting it in helmfile allows us to provide a more docker-compose-like U/X to helm users, but the docker-build feature.

Thoughts?

cc/ @roboll @sstarcher

[sstarcher]

I see this as a job for helm hooks as either a pre-upgrade or a post-upgrade hook. The chart that needs the job to run should be the one running the job.

[mumoshu]

@sstarcher Interesting!

Hooks didn't work for me as, for example, I do run a DB migration separately from a deployment of regular app to avoid down time.

I'd use a hook if the job being run via it is composed of just small, short-running, safe tasks. Not for scheduling a large, long-running batch job paired with the regular server app.

[sstarcher]

ya, it won't work if your application does not understand both database versions to allow for live migrations, but the hook is certainly the preferable mechanism as long as development puts in the time to allow the application to be cleanly upgraded.

[mumoshu]

@sstarcher A change is almost always backward-compatible but it is just that my migration takes a table lock too long due to the size of table :)

I fully agree that hooks are good for dev purpose. Transparent automatic db migration would indeed be valuable for dev envs!

My use-case seems to be more about prod envs.

[sstarcher]

I don't know enough about your situation, but I'm still not sure why you would not wait until you wanted to do the db migration to upgrade the helm chart. That way the migration got kicked off at the appropriate time.

[mumoshu]

@sstarcher Probably you're suggesting the same thing as I do?

I wasn't sure what would be a solution to my problem at the time of writing this issue

But maybe I'd be happy with something like helmfile sync --selector task=migrate-db if it runs helm upgrade --install to run a new db-migration pod. Then, what we'd actually need to implement to support my use-case will be only #28?

[mumoshu]

Or maybe helmfile run --selector task=migrate-db to upgrade the chart labeled with task=migrate-db AND keep tailing logs until the task finishes would be even nicer.

[sstarcher]

@mumoshu ya in that situation #28 should give the main portion. As for tailing the logs that could be a nice feature, but it would likely best be supported under a separate issue and maybe with a flag of --follow or such, but that's a good bit more of a complicated situation.

[mumoshu]

@sstarcher Thanks. Opened #50

[mumoshu]

Hi @gtaylor,
Would this use-case looks like to fit within the scope of helmfile, given it will be supported out-of-box via #28?
Just wanted to sync up with you 😃I appreciate any feedback from you.

[mumoshu]

I'll be closing this once I add a small example about it to README.