Repository navigation
docs(storage): note that the replicated class requires DRBD - #675
Conversation
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
On a substrate where the DRBD kernel module is unavailable the drbd-logger sidecar exits immediately, the satellite pod is therefore never Ready, and piraeus consequently registers zero nodes: LINSTOR reports none, linstor-csi-node hangs in Init polling for a node that does not exist, and every PVC stays Pending behind a cluster that looks healthy. So this flag is the difference between working storage and no storage at all there, not a cosmetic reduction in logging. The concrete case is Talos nodes running as containers. DRBD's resource registry is global per kernel, so three containers sharing one kernel cannot represent three DRBD nodes -- the second new-resource for a given name silently aliases the first instead of failing, which is worse than an error because LINSTOR then records a replica it does not have. It applies to kind equally; it is a property of one kernel, not of Talos. Omitting the sidecar from Cozystack's own pod template is not enough, because piraeus strategically merges satellite configurations and a container another configuration contributes survives the omission. So a LinstorSatelliteConfiguration deletes it from the effective DaemonSet as well. What the flag does NOT do is touch a StorageClass, and the comment says so explicitly. Cozystack does not own them -- an operator writes them by hand from the install guide -- so a class carrying layerList: "drbd storage" still exists after setting this false and volumes on it will never provision. The operator-facing half of that warning goes beside the examples they copy, in cozystack/website#675. Signed-off-by: Myasnikov Daniil <[email protected]>
On a substrate where the DRBD kernel module is unavailable the drbd-logger sidecar exits immediately, the satellite pod is therefore never Ready, and piraeus consequently registers zero nodes: LINSTOR reports none, linstor-csi-node hangs in Init polling for a node that does not exist, and every PVC stays Pending behind a cluster that looks healthy. So this flag is the difference between working storage and no storage at all there, not a cosmetic reduction in logging. The concrete case is Talos nodes running as containers. DRBD's resource registry is global per kernel, so three containers sharing one kernel cannot represent three DRBD nodes -- the second new-resource for a given name silently aliases the first instead of failing, which is worse than an error because LINSTOR then records a replica it does not have. It applies to kind equally; it is a property of one kernel, not of Talos. Omitting the sidecar from Cozystack's own pod template is not enough, because piraeus strategically merges satellite configurations and a container another configuration contributes survives the omission. So a LinstorSatelliteConfiguration deletes it from the effective DaemonSet as well. What the flag does NOT do is touch a StorageClass, and the comment says so explicitly. Cozystack does not own them -- an operator writes them by hand from the install guide -- so a class carrying layerList: "drbd storage" still exists after setting this false and volumes on it will never provision. The operator-facing half of that warning goes beside the examples they copy, in cozystack/website#675. Signed-off-by: Myasnikov Daniil <[email protected]>
Aleksei Sviridkin (lexfrei)
left a comment
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
myasnikovdaniil NOT LGTM. The note is needed, but it presents the flag as a general fix, and it only works on some substrates.
Keeping the change in next/ only is correct. drbd.enabled is on main and in v1.7.0-alpha.3, but not in v1.6.4. What the paragraph says happens without the flag matches the reasoning in packages/system/linstor/values.yaml.
-
The flag fails the render on anything but Talos, and
platform.mdcovers other distributions too.satellites-no-drbd.yaml:1-13in the linstor package refusesdrbd.enabled: falsewhentalos.enabledis false. The generic bundle variants set exactly that. Forisp-full-genericandisp-slim-generic,packages/core/platform/templates/bundles/system.yaml:139-140passestalos.enabled: falseto linstor.platform.mdhas an "Installing on non-Talos OS" section, so a reader on Ubuntu who follows the new advice gets a failed linstor release instead of working local storage. Please say the flag needs Talos nodes. On other distributions the only option today is a working DRBD module on the host, and the chart's error message points at cozystack/cozystack#4092 for the rest.install-cozystack.mdis a Talos-only tutorial, so it is fine as written.disk-encryption.mdserves both, so it needs the same caveat. -
"Loadable" is a narrower condition than the real one. The case the flag was added for is Talos nodes running as containers (
values.yaml:15-22). There the module loads fine, but nodes that share one kernel cannot act as separate DRBD nodes, and the second resource silently aliases the first. A reader on that substrate checks whether the module loads, gets yes, and keepsreplicated. Something like "where DRBD is loadable and each node has its own kernel" covers it. This applies in all three places.
The PR body still says drbd.enabled has not landed in cozystack. It has, so that line can go. i18n-lint is red on stale translations that were on main then, which is unrelated, and the site builds cleanly.
2669d5d to
8d412c3
Compare
8d412c3 to
b6a4643
Compare
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM.
Both of the earlier request-changes points are handled, and the content matches the chart on cozystack main (ba0b1ac6e).
- The Talos-only constraint is now stated in platform.md and disk-encryption.md, the two pages that also serve non-Talos installs, together with the fallback (a loadable DRBD module on the host) and the cozystack/cozystack#4092 tracking link. install-cozystack.md stays without it, which is right for a Talos-only tutorial.
- The condition now reads "loadable and each node has its own kernel" in all three places, so the shared-kernel container case is covered.
Verified against source: packages/system/linstor/values.yaml carries the layerList: "drbd storage" and the per-kernel DRBD registry reasoning, and templates/satellites-no-drbd.yaml fails the render with drbd.enabled=false requires talos.enabled=true, naming #4092, which is exactly what the paragraphs claim.
The PR body no longer says drbd.enabled is absent from cozystack, and next/-only scoping is correct for a feature that is on main but not in v1.6.4.
All findings were reworked
The StorageClass examples in the two install guides and in the disk encryption page are copied verbatim by operators, and nothing beside them says that `layerList: "drbd storage"` is served by a kernel module that may not be present. On a substrate without DRBD the class is created successfully and then every PVC bound to it stays Pending, so the failure surfaces several steps away from the file that caused it. Say it where the class is written, and name the flag that goes with it. The `linstor` package needs `drbd.enabled: false` on such a substrate, and without that the satellite pod never becomes Ready, so LINSTOR registers no nodes and nothing binds at all -- not only the replicated class. LUKS is orthogonal and is called out as such on the encryption page. The flag works on Talos only, so platform.md and disk-encryption.md say so, and "loadable" now also requires that each node has its own kernel, which is the case the flag was added for. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <[email protected]>
b6a4643 to
cf1d454
Compare
StorageClass examples in both install guides and in disk encryption page are copied verbatim by operators, and nothing next to them says
layerList: "drbd storage"needs a kernel module that may not be there. On substrate without DRBD class is created fine and then every PVC on it stays Pending, so failure shows up several steps away from file that caused it.Adds one paragraph next to each example and names the flag that goes with it -
linstorpackage needsdrbd.enabled: falsethere, and without it satellite pod never becomes Ready, so linstor registers no nodes and nothing binds at all, not only replicated class. The flag works on Talos only, chart refuses it on other distributions, soplatform.mdand the encryption page say that. A loadable module is not enough either, Talos nodes running as containers load it but share one kernel, so the condition also says each node has its own kernel. LUKS is independent of DRBD and encryption page says so.drbd.enabledis in main and in v1.7.0-alpha.3, not in v1.6.4, so this goes tonext/only.