Skip to content

Re-enable Helm reconciler concurrency#7378

Open
jnummelin wants to merge 1 commit intok0sproject:mainfrom
jnummelin:re-enable-helm-concurrency
Open

Re-enable Helm reconciler concurrency#7378
jnummelin wants to merge 1 commit intok0sproject:mainfrom
jnummelin:re-enable-helm-concurrency

Conversation

@jnummelin
Copy link
Copy Markdown
Member

Description

We disabled Helm reconciler concurrency in #3633 since the shared Helm state did not support concurrency.

Since we've now moved to ephemeral envs for each Reconcile we can re-enable it safely.

Added a testcase that install two chart with a cross dependency, to make sure the first chart succesfully installs once the later chart brings in the dependency asynchronously. This is bit involved as we need to rely on pre-install Job checking something exists in the API. My first idea was to base the dependency to a service DNS working but turns out CoreDNS is actually borked in the addons test suite since it uses custom Docker network.

Fixes #7305

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update

How Has This Been Tested?

  • Manual test
  • Auto test added

Checklist

  • My code follows the style guidelines of this project
  • My commit messages are signed-off
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules
  • I have checked my code and corrected any misspellings

We disabled Helm reconciler concurrency in k0sproject#3633 since the shared Helm state did not support concurrency.

Since we've now moved to ephemeral envs for each Reconcile we can re-enable it safely.

Added a testcase that install two chart with a cross dependency, to make sure the first chart succesfully installs once the later chart brings in the dependency asynchronously. This is bit involved as we need to rely on pre-install Job checking something exists in the API. My first idea was to base the dependency to a service DNS working but turns out CoreDNS is actually borked in the addons test suite since it uses custom Docker network.

Fixes k0sproject#7305

Signed-off-by: Jussi Nummelin <jnummelin@mirantis.com>
@jnummelin jnummelin requested review from a team as code owners April 1, 2026 13:41
@jnummelin jnummelin requested review from makhov and twz123 April 1, 2026 13:41
@jnummelin jnummelin added bug Something isn't working area/controlplane area/helm backport/release-1.35 PR that needs to be backported/cherrypicked to the release-1.35 branch labels Apr 1, 2026
},
}

as.T().Logf("Creating Chart A (%s) first — it depends on Chart B's Service", chartAName)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be missing something, but I'm not sure using non-existent service can break helm in any circumstances. The more correct check would be installing CRD and corresponding resource in different charts.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This setup is 100% artificial just for testing this cross-chart dependency scenario, for sure. The CRD way is probably closer to real-life scenarios but IMO it does not really matter how this gets tested, as long as we can prove that parallelism works and charts with cross deps gets properly installed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sorry, I got the idea wrong. I was thinking of a scenario where installation of one of the charts might fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/controlplane area/helm backport/release-1.35 PR that needs to be backported/cherrypicked to the release-1.35 branch bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect helm chart installation order

2 participants