justinmclean opened a new pull request, #4609: URL: https://github.com/apache/iggy/pull/4609
## Which issue does this PR address? None. ## Rationale The chart pins `appVersion` to `0.9.0-edge.6`, so an install without `server.image.tag` runs an edge build. ## What changed? This moves the pin to the 0.9.0 release and bumps the chart to 0.7.0. 0.9.0 uses the flat `[encryption]` config, which `server.encryption.configVersion: auto` rejected for any versioned tag after `0.9.0-edge.7`. `auto` now selects `flat` for those tags, so encryption works on the pinned image. Every server tag from `0.9.0-edge.8` to `0.9.1-edge.1` uses `[encryption]`. With persistence on, the chart now uses the `Recreate` strategy, as it already does for `hostNetwork`. A rolling update starts the replacement server while the outgoing one is still running on the same volume. On kind with persistence on, every rollout under the current chart lost the partition's messages, including a plain restart with no version change, on both `0.9.0-edge.6` and `0.9.0`, and rollouts on `0.9.0-edge.6` also reset stored consumer offsets. Moving the pin rolls every release, so this goes in with it. An explicit `server.strategy` still wins. The validate script and the README follow the new pin. The pinned image now renders `IGGY_ENCRYPTION_*`, `0.9.0-edge.8` resolves to `flat` instead of being rejected, and the advertised address section no longer says the pinned image predates the setting. 0.9.0 refuses to start with a wildcard bind and no advertised address, which the chart's default covers. Upgrading from `0.9.0-edge.6`: - With persistence on, the first upgrade moves the Deployment from `RollingUpdate` to `Recreate`. Helm 4's server-side apply rejects that with `spec.strategy.rollingUpdate: Forbidden`, and leaves the release on its old image with its data intact. Run that one upgrade with `--server-side=false`, as the chart README already describes for `hostNetwork`. - 0.9.0 refuses to boot on `IGGY_SYSTEM_*` variables from the old config layout, for example `IGGY_SYSTEM_SHARDING_CPU_ALLOCATION`. Rename any in `server.env` before upgrading. ## Local Execution - Passed: `scripts/ci/test-helm.sh validate` with helm-docs 1.14.2, helmfmt 0.5.0 and yamllint 1.38.0, including the README drift check. - Installed on kind with encryption on. The pod runs `apache/iggy:0.9.0` and reads `IGGY_ENCRYPTION_*` and `IGGY_NODE_ADVERTISED_ADDRESS`. A message sent and polled back matches, and the segment file on disk doesn't contain its plaintext. The kind install also needed `IGGY_SHARDING_CPU_ALLOCATION=2`, as the smoke test notes describe. - New render checks: persistence selects `Recreate`, an explicit strategy overrides it, and a render without persistence sets no strategy. They fail against the current deployment template. - Upgraded a release with persistence and encryption on from the current chart (`0.9.0-edge.6`, `RollingUpdate`) to this one with `--server-side=false`. The Deployment moves to `Recreate`, and messages, a stored consumer offset, a user and its personal access token all read back on 0.9.0 under the same key. - Restarted releases of this chart with persistence on, with and without encryption. Messages, offsets, users and tokens all survive. - Cluster mode was checked by render only. Helm 3 was not tested. - Pre-commit hooks ran ## AI Usage 1. Claude (Claude Code). 2. Drafted the chart, template, validate script and README changes, and ran the kind tests. 3. Ran the validate script and the kind install, upgrade and restart runs listed above. 4. Yes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
