chore(influxdb3-ent): update InfluxDB to 3.11.5 - #852
Conversation
The manual 3.10-to-3.11 upgrade scenario asserted the server version as a literal 3.11.2 after upgrading to the local chart, so it would fail on any later appVersion. It now reads the expected version from Chart.yaml.
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The remaining documentation issue is a non-blocking nit.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Updates the InfluxDB 3 Enterprise chart to version 3.11.5 and aligns the upgrade test with the chart metadata.
Changes:
- Bumps chart version to 0.14.2 and app version to 3.11.5.
- Derives upgrade-test version assertions from
Chart.yaml.
| File | Description |
|---|---|
charts/influxdb3-enterprise/tests/manual/scenarios/upgrade-3.10-to-3.11.sh |
Uses the chart’s app version for upgrade validation. |
charts/influxdb3-enterprise/Chart.yaml |
Updates chart and application versions. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| version: 0.14.0 | ||
| appVersion: "3.11.2" | ||
| version: 0.14.2 | ||
| appVersion: "3.11.5" |
There was a problem hiding this comment.
Fixed the instructions in UPGRADING-3.10-TO-3.11.md: the image override, the byte-count condition, the version check and the verification step now point at the chart's appVersion or say 3.11.2 or later. The sentences saying what chart 0.10.0 shipped stay, since they are accurate about that release. b8caa2f
It told operators with an image override to set 3.11.2-enterprise and to verify that every pod runs 3.11.2, which on a later chart pins an older release and makes a correct upgrade look failed. The instructions now point at the chart's appVersion; statements about what chart 0.10.0 shipped stay as written.
|
Re-checked on kind with the chart's default values rather than the single-replica setup in the description: 2 ingesters, 2 queriers and a compactor, with only the resource requests lowered to fit one test node. After |
bednar
left a comment
There was a problem hiding this comment.
The upgrade guide needs one clarification before approval.
| If your values set `image.tag`, remove the override or change it to | ||
| `3.11.2-enterprise`; otherwise Helm continues deploying the overridden image. | ||
| If your values set `image.tag`, remove the override or change it to the chart's | ||
| `appVersion` with the `-enterprise` suffix (`helm show chart` prints it); |
There was a problem hiding this comment.
This guide still instructs users to upgrade to chart 0.10.0 (and later pins --version 0.10.0), whose appVersion is 3.11.2. This new instruction can instead lead them to use the current chart's 3.11.5 image with the old chart. Please clarify that the image tag must match the chart version used here, or update the guide's upgrade target and commands to the current chart.
There was a problem hiding this comment.
The guide now says the tag has to be the appVersion of the chart version being installed, names 3.11.2-enterprise for the 0.10.0 it uses, and gives the helm show chart --version command for any other version. The verification step says the same. e54b47d
I also merged master after #850 went out as 0.14.1; only the version line conflicted and 0.14.2 stays.
# Conflicts: # charts/influxdb3-enterprise/Chart.yaml
bednar
left a comment
There was a problem hiding this comment.
Reviewed the latest changes. The previous documentation clarification is resolved, and CI checks pass.

Updates the default image to InfluxDB 3 Enterprise 3.11.5, the latest release. Between 3.11.2 and 3.11.5 upstream only fixed bugs: no option was removed or renamed, and the one default that changed (
--snapshot-concurrency-limit) now calls a cached wrapper around the same CPU count, so the rendered manifests differ in the image tag alone. The fixes include compaction that stopped while waiting for memory, a startup stall on large compaction metadata, and filtered queries that missed rows on tables without tags.The manual 3.10-to-3.11 upgrade scenario asserted the server version as a literal 3.11.2 after upgrading to the local chart, so it would have failed from this bump on. It now reads the expected version from
Chart.yaml.Checked on kind with
helm upgrade --reuse-valuesfrom 0.14.0: all four components come up on 3.11.5 without restarts, data written on 3.11.2 is still readable, and thehelm testhook passes.Numbered 0.14.2 to follow #850 (0.14.1). Merging #850 first avoids renumbering it.