Skip to content

chore(linstor): bump linstor-server to 1.33.3 and linstor-csi to v1.11.2#2987

Open
Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
mainfrom
chore/bump-linstor-images
Open

chore(linstor): bump linstor-server to 1.33.3 and linstor-csi to v1.11.2#2987
Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
mainfrom
chore/bump-linstor-images

Conversation

@lexfrei

@lexfrei Aleksei Sviridkin (lexfrei) commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

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-csi v1.10.6 → v1.11.2. Its go.mod requires Go ≥ 1.26, so the CSI builder moves golang:1.25 → golang:1.26 — the right lever for the Go stdlib / moby/spdystream CVEs.

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

chore(linstor): bump linstor-server to 1.33.3 and linstor-csi to v1.11.2

Upgrade impact: an empty tenant Kubernetes worker `nodeGroups[*].storageClass` now defaults to the application-level (DRBD `replicated`) storageClass instead of the management-cluster default, because linstor-csi v1.11.2 rejects ReadWriteMany volumes on a non-DRBD storage class. This changes the rendered worker template, so existing tenant clusters that relied on the empty-storageClass default roll their worker MachineDeployments once on the first reconcile after upgrade — workers are reprovisioned on the application storageClass and container images are re-pulled. The per-nodeGroup override and the both-empty cluster-default escape hatch are preserved.

Summary by CodeRabbit

  • Chores
    • Updated LINSTOR Server to v1.33.3 and LINSTOR CSI to v1.11.2 (image tags/digest pins refreshed)
    • Updated the LINSTOR CSI build toolchain to Go 1.26
    • Added a test make target to run Helm unit tests
  • Documentation
    • Updated the LINSTOR Server patches README to reference v1.33.3
  • Tests
    • Added an image-pinning validation suite to confirm controller and satellite images use sha256 digests

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.

@coderabbitai

coderabbitai Bot commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Note

Reviews paused

It 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 reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

Bumps piraeus-server from 1.33.2 to 1.33.3 and linstor-csi from v1.10.6 to v1.11.2 across the Makefile version variables, CSI Dockerfile (Go builder 1.251.26 and VERSION arg), Helm values.yaml image tags with new SHA256 digests, and the patch README. Adds a helm unittest make target and a new test suite that asserts exact digest-pinned image references for the controller and satellite pods.

Changes

LINSTOR Version Bump and Image-Pin Tests

Layer / File(s) Summary
Version variables, image tags, and builder update
packages/system/linstor/Makefile, packages/system/linstor/images/linstor-csi/Dockerfile, packages/system/linstor/values.yaml, packages/system/linstor/images/piraeus-server/patches/README.md
LINSTOR_VERSION set to 1.33.3, LINSTOR_CSI_VERSION set to v1.11.2; Go builder bumped to 1.26; Helm image tags updated to new versions with updated sha256 digests; README version reference updated to v1.33.3.
Helm unittest suite for image digest pins
packages/system/linstor/tests/linstor_test.yaml
New cozy-linstor image pins suite with two matchRegex tests verifying exact SHA256-pinned image references for controller/CSI controller and satellite pods. The test make target running helm unittest . was also added in the Makefile range above.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Suggested labels

size/S

Suggested reviewers

  • kvaps
  • lllamnyp
  • androndo
  • IvanHunters
  • sircthulhu
  • myasnikovdaniil

Poem

🐇 Hop hop, the versions leap ahead,
From 1.33.2 to .3 instead!
The CSI jumps from .6 to .2,
With Go 1.26 and digests fresh and true.
Tests now pin each image tight,
A bunny-approved CVE-fix delight! 🌿

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately and concisely describes the main change: bumping linstor-server and linstor-csi versions, which matches the primary objectives of the PR.
Linked Issues check ✅ Passed PR successfully bumps LINSTOR and CSI versions, updates Go builder, adds helm-unittest coverage, and verifies all patches apply cleanly, directly addressing security vulnerability fixes in #2881.
Out of Scope Changes check ✅ Passed All changes are scoped to updating LINSTOR components, their dependencies, patches, and adding test coverage—no unrelated modifications detected.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/bump-linstor-images

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, 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

  • LINSTOR Stack Upgrade: Upgraded linstor-server to 1.33.3 and linstor-csi to v1.11.2 to incorporate upstream security fixes and stability improvements.
  • Build Environment Update: Updated the linstor-csi Dockerfile to use Go 1.26 to meet the new dependency requirements of the updated CSI version.
  • Testing and Verification: Added helm-unittest coverage to ensure proper image pinning for the controller, CSI, and satellite components.
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 Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment Gemini (@gemini-code-assist) Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@dosubot dosubot Bot added area/storage Issues or PRs related to storage (linstor, seaweedfs, bucket, velero, harbor) security Security-related issues and features labels Jun 22, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

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.

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

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.

high

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

@github-actions github-actions Bot added size/M This PR changes 30-99 lines, ignoring generated files kind/cleanup Categorizes issue or PR as related to cleanup of code, process, or technical debt labels Jun 22, 2026

@coderabbitai coderabbitai Bot left a comment

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.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 77d42ab and d469a52.

📒 Files selected for processing (5)
  • packages/system/linstor/Makefile
  • packages/system/linstor/images/linstor-csi/Dockerfile
  • packages/system/linstor/images/piraeus-server/patches/README.md
  • packages/system/linstor/tests/linstor_test.yaml
  • packages/system/linstor/values.yaml

Comment thread packages/system/linstor/tests/linstor_test.yaml Outdated
@lexfrei Aleksei Sviridkin (lexfrei) marked this pull request as draft June 23, 2026 01:52

@myasnikovdaniil myasnikovdaniil left a comment

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.

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 + the DrbdPrimary.close() swap both present).
  • The golang:1.25 → 1.26 builder bump is correct and required — linstor-csi v1.11.2's go.mod declares go 1.26.0.
  • The controller/satellite/CSI trio (1.33.3 / 1.33.3 / v1.11.2) is a compatible set.
  • helm template + helm lint clean; 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 replicated PVC 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 produced OFFLINE(VERSION MISMATCH) — expected, just confirms controller and satellites must move together, which the chart already does.)

Blocking:

  • The branch is out of date with main and has a merge conflict in values.yaml. main carries the "Prepare release v1.5.0" commit which rewrote the linstor image tags to the v1.5.0@sha256:... release form. Please rebase on main and re-resolve values.yaml keeping 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 to vX.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 on release-labeled PRs), but consider asserting the invariant that actually holds across dev and release — a digest-pinned cozystack image — e.g. piraeus-server:.+@sha256: and linstor-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:'

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.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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

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.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

@lexfrei Aleksei Sviridkin (lexfrei) marked this pull request as ready for review June 23, 2026 10:04
@dosubot dosubot Bot added the area/build Issues or PRs related to image build infrastructure, multi-arch support label Jun 23, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

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.

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

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.

high

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

@lexfrei

Copy link
Copy Markdown
Contributor Author

myasnikovdaniil addressed your blocker — rebased on main and re-resolved values.yaml keeping the PR's component-version digests (1.33.3@…, v1.11.2@…) as you asked; component-version digest pins are the convention we're standardizing on, so this matches. Also switched the new helm-unittest to the tag-agnostic .+@sha256: invariant you suggested. Head is a8eb83d.

@lexfrei Aleksei Sviridkin (lexfrei) marked this pull request as draft June 23, 2026 11:34
@lexfrei Aleksei Sviridkin (lexfrei) marked this pull request as ready for review June 23, 2026 11:52

@gemini-code-assist gemini-code-assist Bot left a comment

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.

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

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.

high

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

@lexfrei Aleksei Sviridkin (lexfrei) force-pushed the chore/bump-linstor-images branch 3 times, most recently from 9055987 to 890b3d1 Compare June 24, 2026 12:29
@lexfrei

Copy link
Copy Markdown
Contributor Author

myasnikovdaniil rebased onto current main — the release-prep v1.5.0@sha256: tags are re-resolved back to the component-version digests you verified (piraeus-server:1.33.3@1f8317fc…, linstor-csi:v1.11.2@36f33dc8…), same bytes, no conflict left. helm-unittest is green and the tag-agnostic .+@sha256: assertions hold across dev and release re-tag. Head is 890b3d1.

@github-actions github-actions Bot added size/L This PR changes 100-499 lines, ignoring generated files and removed size/M This PR changes 30-99 lines, ignoring generated files labels Jun 24, 2026
@lexfrei Aleksei Sviridkin (lexfrei) added the area/kubernetes Issues or PRs related to the tenant Kubernetes app label Jun 24, 2026
@IvanHunters

Copy link
Copy Markdown
Collaborator

Verdict

NOT LGTM — pending rebase

Concurring with myasnikovdaniil: the branch is out of date with main and the touched values.yaml contains a content conflict against the Prepare release v1.5.0 commit. The image bumps and the coupled storageClass fallback themselves are coherent and necessary — happy to flip to LGTM once the rebase lands. Adding two upgrade-impact notes and one unittest-robustness note found independently while reviewing.

Findings

[MAJOR] packages/system/linstor/values.yaml — branch is out of date with main; content conflict against the v1.5.0 release commit

main carries e1aaa90e Prepare release v1.5.0, which rewrote piraeusServer.image.tag and linstorCsi.image.tag from component-version digests to the v1.5.0@sha256:… release form. This PR's HEAD (a4e12a1d) edits the same two keys with the component-version digests (1.33.3@sha256:…, v1.11.2@sha256:…). The two edits collide on identical lines, so a rebase will surface a manual conflict. Resolve in favour of this PR's component-version digests (the release-prepare workflow rewrites them to v1.5.x@sha256:… on the next release cut anyway). This is the only blocker.

[MINOR] packages/system/linstor/tests/images_test.yaml — unittest assertions hardcode the component-version tag prefix and will fail on a release-prepare commit

The new images_test.yaml asserts that the rendered container images literally start with piraeus-server:1.33.3@sha256: and linstor-csi:v1.11.2@sha256:. The repo's release-prepare workflow rewrites those tags to v<RELEASE>@sha256:… (proof: the v1.5.0 release-prepare commit above), so the assertions stop matching on the release commit. Today this is masked because the unit-test job is skipped on release-labeled PRs, but the invariant the test should be encoding is "cozystack-built digest-pinned image" — not "this specific upstream version". Suggested fix: assert against a regex like piraeus-server:.+@sha256:[0-9a-f]{64}$ (and same for linstor-csi). That holds across dev AND release commits and still catches a missing digest pin.

[MINOR] packages/apps/kubernetes/templates/cluster.yaml:59 — silent worker MachineDeployment roll on upgrade for tenants with non-replicated cluster default

For any existing tenant Kubernetes HelmRelease where nodeGroups[*].storageClass: "" and the management-cluster default StorageClass differs from replicated, this change flips the rendered storageClassName from omitted to replicated. The KubevirtMachineTemplate name is hash-pinned over the rendered template body, so the hash changes, a new KubevirtMachineTemplate is produced, and the MachineDeployment's infrastructureRef updates — provoking a rolling replacement of every worker VM in those groups. Existing worker disks (kubelet state, containerd image cache) are abandoned and reprovisioned on the new StorageClass; tenant workloads are evicted and rescheduled, and every container image is re-pulled on the new nodes. This is the safest path given the linstor-csi v1.11.0 RWX-on-non-DRBD rejection, but it should be called out explicitly in the release-note block so cluster operators planning the upgrade window expect worker churn and image-pull traffic.

Suggested release-note addendum: "Upgrade impact: tenant Kubernetes clusters whose worker nodeGroups[*].storageClass was left empty AND whose management-cluster default StorageClass is not the application-level (DRBD-backed) storageClass will see their worker MachineDeployments roll once on next reconcile — workers are reprovisioned on the application storageClass."

[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 dataVolumeTemplates do not set accessModes: [ReadWriteMany]; the resulting PVC access mode is whatever the CDI StorageProfile for the chosen StorageClass emits. For DRBD-backed classes the piraeus-operator-supplied StorageProfile produces RWX so live-migration works; for an arbitrary non-DRBD cluster-default class the access mode could be RWO, in which case the linstor-csi v1.11.0 RWX-on-non-DRBD rejection path doesn't even apply. The fallback is still defensively correct, but the framing slightly overstates the failure mode.

Caveats

  • linstor-server 1.33.3 also disables DRBD shrink (per LINBIT release notes between 1.33.2 and 1.33.3). The PR body lists positive 1.33.3 fixes but omits this regression. Operators relying on volume shrink (rare) need to know.
  • Multi-arch (linux/arm64) for ghcr.io/cozystack/cozystack/linstor-csi@sha256:36f33dc8… could not be independently verified from the diff alone; only the piraeus-server multi-arch manifest was confirmed at review time. Worth a docker manifest inspect eyeball on both digests before tagging a cozystack release.
  • linstor-csi v1.11.2 also enables "Only allow DRBD two-primaries for kubevirt deployments by default" (per upstream changelog) in addition to the documented RWX gate. Not a blocker for cozystack (kubevirt is the target), but worth knowing it's a second behaviour shift in the same bump.

Recommended follow-ups

  • Extend the release-note block with the worker-roll heads-up described in Findings.
  • After merge, document in the operator-facing upgrade notes that tenants left on a non-replicated cluster-default will see a one-shot worker rotation.

@lexfrei

Copy link
Copy Markdown
Contributor Author

Reworked per review — rebased on current main (conflict resolved, component-version digests kept; git merge-tree is clean and the PR shows mergeable) and addressed the feedback:

  • Pin test tightened to the anchored digest form ^…/<image>:[^@]+@sha256:[0-9a-f]{64}$ — version-agnostic so it survives the release-prepare re-tag, while enforcing a full 64-hex digest. Matches the existing kuberture / busybox pin tests.
  • Worker storageClass upgrade impact is now both tested and documented. New hash-pin tests prove the empty-nodeGroup default renames the KubevirtMachineTemplate (e20c17b86ac1), so the one-time worker-pool roll on in-place upgrade is a guarded, intentional change; the release note calls it out for upgraders.
  • RWX framing corrected in the template comment, the field doc, and the generated schema / README: the worker DataVolume sets no accessModes — RWX comes from the chosen StorageClass's CDI StorageProfile.
  • Both image digests re-verified multi-arch (amd64 + arm64).
  • Body now notes that 1.33.3 disables DRBD volume shrink upstream and csi v1.11.2 defaults two-primaries to kubevirt-only — both no-ops for cozystack.

@github-actions github-actions Bot added size/M This PR changes 30-99 lines, ignoring generated files and removed size/L This PR changes 100-499 lines, ignoring generated files labels Jun 29, 2026
@lexfrei

Copy link
Copy Markdown
Contributor Author

myasnikovdaniil rebased onto main — the values.yaml conflict against the v1.5.0 release-prep is resolved, keeping the component-version digests as you directed. This was your only blocker; ready for your re-review when you have a moment.

@lexfrei Aleksei Sviridkin (lexfrei) force-pushed the chore/bump-linstor-images branch 3 times, most recently from aeb0543 to 949885e Compare July 1, 2026 11:10
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/build Issues or PRs related to image build infrastructure, multi-arch support area/kubernetes Issues or PRs related to the tenant Kubernetes app area/storage Issues or PRs related to storage (linstor, seaweedfs, bucket, velero, harbor) kind/cleanup Categorizes issue or PR as related to cleanup of code, process, or technical debt security Security-related issues and features size/M This PR changes 30-99 lines, ignoring generated files

Projects

None yet

Development

Successfully merging this pull request may close these issues.

chore(linstor): bump system/linstor images to current upstream release

3 participants