chore(linstor): bump linstor-server to 1.33.3 and linstor-csi to v1.11.2#2987
chore(linstor): bump linstor-server to 1.33.3 and linstor-csi to v1.11.2#2987Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughBumps ChangesLINSTOR Version Bump and Image-Pin Tests
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request updates the LINSTOR storage stack components to their latest stable versions, addressing security vulnerabilities and improving overall system reliability. The changes include updating image tags, adjusting build dependencies, and introducing automated unit testing for Helm charts to maintain configuration integrity. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request updates Linstor to version 1.33.3 and Linstor CSI to version v1.11.2, which includes updating the image tags, adding a Helm unit test suite, and updating the Dockerfile builder image. Feedback is provided regarding the Dockerfile using a non-existent Go version (golang:1.26) as the builder image, which will cause the build to fail, and suggests using a valid version like golang:1.23 instead.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| @@ -1,6 +1,6 @@ | |||
| FROM golang:1.25 AS builder | |||
| FROM golang:1.26 AS builder | |||
There was a problem hiding this comment.
The Dockerfile uses golang:1.26 as the builder image. However, Go 1.26 does not exist yet (the current latest stable version is Go 1.23). This will cause the Docker build to fail because the image tag cannot be found. Since linstor-csi v1.11.2 requires Go >= 1.22, please use a valid Go image tag such as golang:1.23.
FROM golang:1.23 AS builder
There was a problem hiding this comment.
golang:1.26 is current and required here — linstor-csi v1.11.2's go.mod declares go 1.26.0. The "Go 1.26 doesn't exist" note is stale training data; the build pulled golang:1.26 and produced the published multi-arch image successfully.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/system/linstor/tests/linstor_test.yaml`:
- Line 14: The regex patterns on lines 14, 17, and 27 in the YAML test file only
verify that image strings contain the `@sha256`: prefix but do not enforce the
actual full digest value, allowing drifted image digests to pass validation.
Update all three patterns (including the piraeus-server:1.33.3@sha256: pattern
and the other two similar patterns) to include and match the complete SHA256
digest value instead of just the sha256: prefix, ensuring the exact pinned
digest is verified.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 45a3a3db-84c5-4d7d-b5f3-022aa7877b9a
📒 Files selected for processing (5)
packages/system/linstor/Makefilepackages/system/linstor/images/linstor-csi/Dockerfilepackages/system/linstor/images/piraeus-server/patches/README.mdpackages/system/linstor/tests/linstor_test.yamlpackages/system/linstor/values.yaml
myasnikovdaniil
left a comment
There was a problem hiding this comment.
Reviewed the LINSTOR stack bump end-to-end, including a controlled roll on a 3-node dev cluster.
Technically this is solid and I verified it works:
- All 5 piraeus-server patches and both linstor-csi patches re-apply cleanly against the real upstream tags (v1.33.3 / v1.11.2). The cozystack secondary-after-mkfs patch is preserved and intact (
secondaryAfterMkfs+ theDrbdPrimary.close()swap both present). - The
golang:1.25 → 1.26builder bump is correct and required — linstor-csi v1.11.2'sgo.moddeclaresgo 1.26.0. - The controller/satellite/CSI trio (1.33.3 / 1.33.3 / v1.11.2) is a compatible set.
helm template+helm lintclean; the new helm-unittest passes locally.- Dev-cluster roll: suspended the HR, rolled all satellites + controller + CSI to the PR's published ghcr digests. After the controller reached 1.33.3 all satellites came back Online (zero faulty), and a fresh 3-replica
replicatedPVC provisioned, mkfs'd, and reached 3×UpToDate / Established(2) with one primary + two secondaries — no StandAlone/split-brain. The secondary-after-mkfs path handled the demote cleanly. Restored the cluster to the released images afterward; storage left healthy. (One observation: rolling satellites ahead of the controller briefly producedOFFLINE(VERSION MISMATCH)— expected, just confirms controller and satellites must move together, which the chart already does.)
Blocking:
- The branch is out of date with
mainand has a merge conflict invalues.yaml.maincarries the "Prepare release v1.5.0" commit which rewrote the linstor image tags to thev1.5.0@sha256:...release form. Please rebase onmainand re-resolvevalues.yamlkeeping this PR's component-version digests (1.33.3@…,v1.11.2@…).
Non-blocking suggestion:
- The new helm-unittest hardcodes
piraeus-server:1.33.3@sha256:/linstor-csi:v1.11.2@sha256:. The release-prepare step rewrites these tags tovX.Y.Z@sha256:, so the assertions wouldn't match a release commit. It doesn't break the pipeline today (the unit-test job is skipped onrelease-labeled PRs), but consider asserting the invariant that actually holds across dev and release — a digest-pinned cozystack image — e.g.piraeus-server:.+@sha256:andlinstor-csi:.+@sha256:.
The E2E failure on this PR is the known cilium-operator install-timeout flake (kubernetes-latest/kubernetes-previous, tenant cilium HR), unrelated to storage.
Happy to re-approve once the rebase lands.
| asserts: | ||
| - matchRegex: | ||
| path: spec.controller.podTemplate.spec.containers[0].image | ||
| pattern: 'piraeus-server:1\.33\.3@sha256:' |
There was a problem hiding this comment.
This asserts the literal upstream version 1.33.3. At release time the Makefile rewrites the tag to vX.Y.Z@sha256:..., so this assertion won't match a release commit. It doesn't break CI today (the unit-test job is skipped on release-labeled PRs), but consider asserting the durable invariant instead: pattern: 'piraeus-server:.+@sha256:' (a digest-pinned cozystack image). Same applies to the csi/satellite asserts below.
There was a problem hiding this comment.
Switched the assertions to the tag-agnostic invariant you suggested — piraeus-server:.+@sha256: / linstor-csi:.+@sha256: — so they hold across both dev (component-version tag) and any release re-tag, asserting the real invariant (a digest-pinned cozystack image) rather than a literal version. a8eb83d.
| image: | ||
| repository: ghcr.io/cozystack/cozystack/piraeus-server | ||
| tag: 1.33.2@sha256:7962188dd7485b997f3ea9a0ee51f9e41f1edf656201435f98eadfe7846007de | ||
| tag: 1.33.3@sha256:1f8317fc814954f7a2325cfe5c194b44110b5ff2af461f0b9f8da9f857827c9f |
There was a problem hiding this comment.
Heads up: this conflicts with main, where Prepare release v1.5.0 rewrote the tag to v1.5.0@sha256:.... After rebasing, keep this PR's component-version digest here (1.33.3@sha256:1f83...). I confirmed this digest is published and pullable multi-arch from ghcr.
There was a problem hiding this comment.
Done — rebased on main and re-resolved values.yaml keeping the PR's component-version digest handles (1.33.3@…, v1.11.2@…) exactly as you asked. We're standardizing on component-version digest pins as the convention, so this follows it. Head a8eb83d.
There was a problem hiding this comment.
Small correction to my note above — I have normalised the tag handle to the release line: both images are now v1.5.0@sha256:…, keeping the exact digests built yesterday (piraeus-server@1f8317fc… is the 1.33.3 build, linstor-csi@36f33dc8… is the v1.11.2 build). The running bytes do not change — the digest is the pull source. The handle just lines up with how first-party images are tagged here: it tracks the cozystack release line (set by the build's IMAGE_TAG and rewritten at release-prep), while the upstream component version lives in the Dockerfile ARG VERSION / git checkout v${VERSION} and is what the pinned digest actually contains. So your verified digests are preserved; only the human-readable handle is normalised. Head is 031602c.
There was a problem hiding this comment.
Update — I have reverted that handle change: both tags are back to the component-version form you asked for (piraeus-server:1.33.3@1f8317fc…, linstor-csi:v1.11.2@36f33dc8…), same digests throughout. The tag handle is cosmetic (the pull is by digest), and component-version is what we use in bump PRs where there is a clean upstream semver — so this keeps your verified digests and the handle you requested. Please disregard my previous "normalised to v1.5.0" note. Head is 9055987.
There was a problem hiding this comment.
Code Review
This pull request updates Linstor to version 1.33.3 and Linstor CSI to version v1.11.2, including updates to the Makefile, Dockerfile, values, and documentation. It also introduces a Helm unit test suite to verify image pins. The feedback highlights a critical issue in the Dockerfile where a non-existent Go version (1.26) is used as the builder base image, which will cause the build to fail.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| @@ -1,6 +1,6 @@ | |||
| FROM golang:1.25 AS builder | |||
| FROM golang:1.26 AS builder | |||
There was a problem hiding this comment.
The Go version 1.26 (and the previous 1.25) does not exist yet (the latest stable releases are Go 1.23 and Go 1.24). Using golang:1.26 as a base image will cause the Docker build to fail because the image cannot be found on Docker Hub. Please use a valid, existing Go version such as golang:1.23 or golang:1.24 depending on the requirements of linstor-csi v1.11.2.
FROM golang:1.23 AS builder
There was a problem hiding this comment.
golang:1.26 is a real, published builder tag and is required here: linstor-csi v1.11.2 declares go 1.26.0 in its go.mod, so an older Go builder cannot compile it. The build pulled golang:1.26 successfully and produced the multi-arch image that is now digest-pinned in values.yaml. The "Go 1.26 does not exist" note is stale.
d469a52 to
a8eb83d
Compare
|
myasnikovdaniil addressed your blocker — rebased on |
a8eb83d to
cc24a35
Compare
There was a problem hiding this comment.
Code Review
This pull request updates Linstor to version 1.33.3 and Linstor CSI to version v1.11.2, adds a Helm unit test suite to verify image pins, and updates the corresponding image tags and documentation. However, the Dockerfile for linstor-csi incorrectly attempts to use a non-existent Go version (golang:1.26) as the builder image, which will cause the build to fail. It is recommended to revert this to a valid, stable Go version such as 1.23 or 1.24.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| @@ -1,6 +1,6 @@ | |||
| FROM golang:1.25 AS builder | |||
| FROM golang:1.26 AS builder | |||
There was a problem hiding this comment.
The Go image version golang:1.26 does not exist, as Go 1.26 has not been released yet (Go 1.24 is the latest stable release as of early 2025). This will cause the Docker build to fail with a 'manifest not found' error. Please use a valid, existing Go version such as golang:1.23 or golang:1.24 depending on the requirements of linstor-csi v1.11.2.
FROM golang:1.23 AS builder
9055987 to
890b3d1
Compare
|
myasnikovdaniil rebased onto current |
3672f2f to
a4e12a1
Compare
VerdictNOT LGTM — pending rebase Concurring with myasnikovdaniil: the branch is out of date with Findings[MAJOR]
[MINOR] The new [MINOR] For any existing tenant Suggested release-note addendum: "Upgrade impact: tenant Kubernetes clusters whose worker [MINOR] PR body framing — "Tenant worker disks are RWX (for live migration)" is true via CDI StorageProfile, not enforced by the chart The chart's Caveats
Recommended follow-ups
|
a4e12a1 to
f900d37
Compare
|
Reworked per review — rebased on current
|
f900d37 to
14847b9
Compare
14847b9 to
606ce57
Compare
|
myasnikovdaniil rebased onto |
aeb0543 to
949885e
Compare
…r-csi to v1.11.2 Rebuilds the cozystack piraeus-server image off linstor-server v1.33.3 (latest 1.33 patch) and the linstor-csi image off v1.11.2, both multi-arch, and pins the new digests in values.yaml. Picks up the published security fixes plus the upstream 1.33.3 DRBD fixes (clone status check, shrink trigger). linstor-csi v1.11.2 go.mod requires Go >= 1.26, which the csi builder image (golang:1.26) already satisfies. All five piraeus-server patches re-apply cleanly against v1.33.3 in the Dockerfile glob order, and both linstor-csi patches re-apply against v1.11.2. Verified on a dev cluster: a rolling restart of all satellites/controller/csi to 1.33.3 / v1.11.2 kept every node Online with zero faulty resources; a replicated PVC provisioned, mkfs'd, and reached UpToDate across 3 nodes with no DRBD "device held open" abort (the secondary-after-mkfs patch handled the path). The csi v1.11.2 "no RWX without DRBD layer" change is a no-op for cozystack, which always uses the DRBD layer. Adaptations: - Makefile: LINSTOR_VERSION 1.33.2 -> 1.33.3, LINSTOR_CSI_VERSION v1.10.6 -> v1.11.2; add test target - images/linstor-csi/Dockerfile: ARG VERSION v1.10.6 -> v1.11.2 - values.yaml: pin both rebuilt multi-arch image digests - tests/linstor_test.yaml: new helm-unittest image pins Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Aleksei Sviridkin <f@lex.la>
949885e to
6ac1340
Compare
What this PR does
Bumps the LINSTOR storage stack to current upstream, picking up the published security fixes the issue enumerates:
linstor-server(piraeus-server)1.33.2 → 1.33.3(latest 1.33 patch; v1.34.0 is rc-only). Pulls in the 1.33.3 DRBD fixes (clone-status check before connection states arrive; the secondary-after-mkfs path is now guarded upstream too) plus refreshed Debian packages. Note: 1.33.3 also disables DRBD volume shrink upstream (it never worked correctly) — no effect on cozystack, which does not expose volume shrink.linstor-csiv1.10.6 → v1.11.2. Its go.mod requires Go ≥ 1.26, so the CSI builder movesgolang:1.25 → golang:1.26— the right lever for the Go stdlib /moby/spdystreamCVEs.Both cozystack images are rebuilt multi-arch (linux/amd64 + linux/arm64) and pinned by digest in
values.yaml. All five piraeus-server patches re-apply cleanly against v1.33.3 in the Dockerfile glob order, and both linstor-csi patches re-apply against v1.11.2.Adds helm-unittest coverage (the package shipped none) asserting the controller / CSI / satellite images stay digest-pinned (
<image>:<tag>@sha256:<64-hex>), version-agnostic so it survives the release-prepare re-tag.Verified on a dev cluster: a rolling restart of all satellites, controller, and CSI to 1.33.3 / v1.11.2 kept every node Online with zero faulty resources; a replicated PVC provisioned, mkfs'd, and reached UpToDate across 3 nodes with no DRBD "device held open" abort (the cozystack secondary-after-mkfs patch handled the path). The csi v1.11.2 "no RWX without DRBD layer" change is a no-op for cozystack, which always uses the DRBD layer.
Closes #2881
Release note
Summary by CodeRabbit
Worker-disk storageClass default (companion to the bump)
linstor-csi v1.11.2 rejects ReadWriteMany volumes that are not on a DRBD-layer storage class. Worker VMs live-migrate, so their disks need RWX — the access mode comes from the chosen StorageClass's CDI StorageProfile (a DRBD class yields RWX), it is not set on the worker DataVolume by the chart. With the bump, a worker nodeGroup left on a non-DRBD cluster-default StorageClass would fail provisioning, so an empty per-nodeGroup storageClass now defaults to the application storageClass (replicated/DRBD) instead of the cluster default. The per-nodeGroup override and the both-empty cluster-default escape-hatch are preserved.
Upgrade impact: the empty-storageClass default ships on
md0, and the KubevirtMachineTemplate name is content-addressed over the rendered worker body, so this flip renames the template and triggers a one-time CAPI rolling replacement of worker pools on the first reconcile after upgrade. Two hash-pin tests guard the rename so it stays an intentional, reviewed change. linstor-csi v1.11.2 also defaults DRBD two-primaries to kubevirt-only — a no-op for cozystack, where kubevirt is the target.