Helmfile: parallel helm installs

[skeenan947]

Helmfile should support installing multiple releases at the same time rather than doing them in serial.
In addition, there should be a way to set an order of dependencies, in case one install is dependent on another.

[mumoshu]

@skeenan947 Hey!

helmfile already support --concurrency=N which allows you to set the number of concurrent releases being processed by helmfile, and it's set to the number of releases within the helmfile.yaml by default.

For controlling the installation order, sub-helmfiles listed under helmfiles: cna be used, as each sub-helmfile is processed sequentially, whereas the releases in a single helmfile is processed concurrently.

Does it help your use-case?

[skeenan947]

@mumoshu thank you, I didn't see concurrency in the docs when I looked. I must've missed it.
re: dependency order, that's helpful, but doesn't completely solve the issue. I'd love to have more granular control - we can hack something together with multiple Helmfiles, but it'll be clunky and hard to follow. Would much prefer to have something like a group# in each release that controls order and defines which Helm charts to install together, and what groups are dependent on previous groups.

[mumoshu]

@skeenan947 Hey! Thanks for your response.

which Helm charts to install together, and what groups are dependent on previous groups.

This looks exactly what helmfiles: provides you. Would you mind giving me a configuration example with the desired feature?

[naseemkullah]

helmfile already support --concurrency=N which allows you to set the number of concurrent releases being processed by helmfile, and it's set to the number of releases within the helmfile.yaml by default.

Hi @mumoshu, does this work out of the box if we are using helmfile.d/foo.yaml for example? or does the file need to be called helmfile.yaml for concurrency=#-of-releases to work?

[mumoshu]

@naseemkullah Hey!

Unfortunately, helmfile.d is designed as it sorts all the files under the directory in alphabetical order, and runs it sequentially. In each helmfile all the releases are processed concurrently, which is configurable via --concurrency.

So yes, it must be a single helmfile.yaml (although the name doesn't matter) to make the releases processed concurrently. This is unlikely to change, as a helmfile state file is treated as an unit of job, so that helmfile.d or sub-helmfiles can be used for ordering.

As a work-around, if your helmfiles are simple enough, you should be able to use bases: to merge all the helmfile state files under your helmfile.d, which produces a single big helmfile state file that all the releases originally defined in different state files are processed concurrently.

bases:
- helmfile.d/00-a.yaml
- helmfile.d/00-b.yaml
# ...

[naseemkullah]

Thanks @mumoshu!

[abdennour]

Does --concurrency=N is still supported with the latest versions ?

[mumoshu]

Yes

[razsha]

Hey @mumoshu !
I understand the idea of treating a helmfile as a single unit. but, you might want the ability to both run a single "component" (sub-helmfile) + run all components in parallel. even more, you might want to run one 'tier' in parallel and another serially.
I thought about 2 options:

1. A helmfile flag that disables this behavior of sequentially.
2. Add to helmfiles: a sub attribute for folders you want to run in parallel.

WDYT?

[mumoshu]

@razsha Hey! I'm not saying no to the request feature but I do have concerns.

The first option breaks declarativeness of helmfile.yaml, cuz it alters the meaning of a helmfile.yaml depending on a command-line flag.

So the latter would be a better direction.

But note that currently any helmfiles: entry is processed sequentially assuming the order matters, and files in a directory specified via helmfiles: is also processed sequentially in alphabetical order assuming the user is using file names to control the order. So depending on the use-case, we may need to make both configurable. But what would be the best API to express that?

Also, helmfile has an alterative mode that allows you to specify a directory containing multiple helmfile.yaml files via helmfile -d PATH/TO/DIR. If you make the file ordering configurable, we also need to make it configurable via a command-line flag, and it breaks the declarativeness of the dir cuz the installation order within a directory is now dependent on the flag.

Given all that, I guess our best bet would be to give up controlling order of files under the directory, and only allow controlling the order and the parallelism of helmfiles: entries, extending the DAG feature(releases[].needs) to sub-helmfiles.

helmfiles:
- name: infra
  path: helmfile.infra.yam
- name: apps1
  path: helmfile.apps1.yaml 
  needs: infra
- name: apps2
  path: helmfile.apps2.yaml 
  needs: infra

This results in Helmfile computing a DAG of helmfiles [ infra ] <-- depends on [app1, app2]. As app1 and app2 being independent to each other after infra is given, helmfile will automatically install infra first, and then concurrently install app1 and app2.

Would that work for you?

[razsha]

Thanks @mumoshu !
Yes, I think it's a good idea to express it via helmfiles:. it might be a breaking change for everyone who assumes that sub-helmfiles run sequentially, but the needs is a good alternative.

[ostlerc]

am I understanding this correctly?
if you have a globbing top level helmfile like

helmfiles:
- apps/*/helmfile.yaml

then all nested helmfiles would run in serial?

[mumoshu]

Yes