Ability to configure concurrent installs vs upgrades

[dmarkey]

Hi,

We have a helm chart that is big and takes a while to install has it has a lot of pre-install hooks, so we have concurrency set low.

However we have 50+ instances of the helm chart, so this makes upgrades slow to roll out.

The ability to configure concurrency differently for installs vs upgrades would solve this problem for us.

Thanks!

David

[hiddeco]

Concurrency is configured at HelmRelease level and installations and upgrades are processed by the same worker pool, changing this is not feasible at the moment.

I am willing to look at alternatives to this, using e.g. virtual "pools" which would re-queue until there is place for the action they want to perform. But this has to wait till further architectural changes have landed, as the current structure of the code hardly allows for this in a sane way.

[dmarkey]

Thank you!