chore(mayastor): remove the code, the laptop roll and the dead image bake #246
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/mayastor-repo-cleanup"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The objects were deleted from the cluster on 2026-09-04. This removes what delivered them, plus two adjacent piles of dead code, and adds the guard that keeps them gone. 50 files, 5940 deletions.
What goes
regen-diskpools.sh, four blocks ink3s-remove-node.sh(468 → 225 lines), the alert rules, the egress-denylist entry, 17 inventory recordsscripts/bench/fio-bench.yamlheld the repo's lastmayastor-repl5referencek3s-roll.sh,lib/roll-common.sh, and theroll/roll-dry-run/roll-staletargetsbuild-platform-base.sh,build-platform-image.sh,render-grub-cfg.shThe roll goes because whole-node work is moving into the pipeline the way the kernel roll already did, and a laptop script that can delete nodes and PersistentVolumes is a capability nobody should reach for by reflex. The primitives it drove remain —
k3s-add-node.shandk3s-create.share whatmake cluster-createandrun-rebuild.shuse.The image bake goes because it is not merely dead:
build-node-image.sh:4-5has declared it replaced for months, and its presence twice sent a planning pass to the wrong files, because it still contains a plausible-looking partition carve and ahugepages=1024cmdline. The live equivalents are insean/builder-images,images/node-bootc.Three things deliberately kept
k3s-remove-node.shPhase 3. It selects onopenebs.io/nodeid, which is ZFS LocalPV's node-affinity key, not Mayastor's. 30 live volumes match on it, and the repartition workflow ports this code.natsio/inventory exemption. It reads as a Mayastor line, butargo-events/manifest.yamluses those images too, so deleting it turns the guard red. Verified, and its reason rewritten.WORKER_AMD64_COUNT=5. Its comment credited "mayastor repl=5 + etcd 5-voter quorum" — both clauses were Mayastor, the second being mayastor-etcd. Left alone, this change would erase the only written reason for a five-worker pool. Rewritten to cite what survives: CNPGinstances: 5, OpenBaoreplicas: 5, and MinIO's two erasure sets of five at write quorum 3.CHANGELOG.mdanddocs/archiveare untouched. That history is accurate.Captured before deletion
k3s-remove-node.shPhase 8 was the only written record of how to clear a wedged DiskPool, including the 2026-08-14 incident where a stale pool refused the seanfarm32 roll outright. The full procedure is preserved in the commit message rather than lost with the file.The guard
tests/mayastor-retired.sh, modelled ontests/retired-crd-refs.sh, wired intotests/check.sh. Three halves, because a guard whose only success condition is "the scan matched nothing" passes vacuously the day someone deletes what it protects. Half 2 asserts every survivor by explicit non-zero count: the ZFS driver,openebs-zfsin the egress denylist, Phase 3 and its selector, and all three reasons the pool is five workers.Verified by mutation, not assumption. Reintroducing a
mayastor-*StorageClass, deleting the ZFS driver manifest, and renaming Phase 3 each turn it red. It also caught its own first draft passing vacuously, where a pattern beginning with-was read by grep as an option.Checks
tests/check.shexits 0.every-guard-has-a-callerreports 62 guards, 50 gated by CI. Every touched kustomization renders with zero Mayastor references.rules.yamlstill holds five PrometheusRules and the Cilium policy still denies egress toopenebs-zfs.https://claude.ai/code/session_01MdSbMhzabSbpG8TtP9Ur3H
The objects were deleted from the cluster on 2026-09-04. This removes what delivered them, plus two adjacent piles of dead code, and adds the guard that keeps them gone. WHAT GOES, AND WHY EACH ONE Mayastor itself: both manifest directories (2055 lines of vendored helm render among them), scripts/regen-diskpools.sh, the four Mayastor blocks in k3s-remove-node.sh, the alert rules, the egress-denylist entry, and 17 records from tests/upstream-inventory.txt. scripts/bench/ in full. Its README opens "Mayastor nvme-tcp benchmark", run-bench.sh queries diskpools, and fio-bench.yaml held the repository's last mayastor-repl5 reference. The suite has no purpose without Mayastor. The laptop replace-roll: scripts/k3s-roll.sh, scripts/lib/roll-common.sh and the roll / roll-dry-run / roll-stale Makefile targets. Whole-node work is moving into the pipeline the way the kernel roll already did, so a laptop script that can delete nodes and PersistentVolumes is a capability nobody should reach for by reflex. The primitives it drove REMAIN: k3s-add-node.sh and k3s-create.sh are what `make cluster-create` and run-rebuild.sh use, and k3s-remove-node.sh Phase 3 is the orphan-volume cleanup the repartition workflow will port. The retired ZFS-on-root bake: build-platform-base.sh, build-platform-image.sh and render-grub-cfg.sh. build-node-image.sh:4-5 has declared them replaced for months and nothing invokes them. They are not merely dead — their presence twice sent a planning pass to the wrong files, because they still contain a plausible-looking partition carve and `hugepages=1024` cmdline. The live equivalents are in sean/builder-images, images/node-bootc. WHAT DELIBERATELY STAYS k3s-remove-node.sh Phase 3, the orphan PVC/PV cleanup. It selects on openebs.io/nodeid, which is ZFS LocalPV's node-affinity key and not Mayastor's; 30 live volumes match on it. tests/upstream-inventory.sh's `natsio/` exemption. It reads as a Mayastor line but argo-events/manifest.yaml uses those images too, so deleting it turns the guard red. WORKER_AMD64_COUNT=5. Its comment credited "mayastor repl=5 + etcd 5-voter quorum" — BOTH clauses were Mayastor, the second being mayastor-etcd. Left alone, removing Mayastor would erase the only written reason for a five-worker pool and invite someone to shrink it. The comment is rewritten to cite the reasons that survive: CNPG instances: 5, OpenBao replicas: 5, and MinIO's two erasure sets of five with write quorum 3. CHANGELOG.md and docs/archive are untouched. That history is accurate. CAPTURED BEFORE DELETION: clearing a wedged DiskPool k3s-remove-node.sh Phase 8 was the only written record of this, so it is preserved here. Deleting a VM did not retire its DiskPool: the replicas died with the disk, the volumes rebuilt elsewhere leaving UNOWNED replica specs, the pool then reported InUse, and its CR hung on the openebs.io/diskpool-protection finalizer forever because destroying a pool needs an io-engine on a node that no longer exists. That residue blocked kernel rolls permanently — it did on 2026-08-14, when the seanfarm32 roll refused with "mayastor-pools-not-ready=[...069094(stale)]". The recovery was: wait for rebuilds to finish first, since a pool with a replica still copying off is genuinely in use; ask the REST API to destroy the pool and expect it to refuse with 409 InUse, then 412 once the node went Offline; then remove the pool spec and its orphaned replica specs directly from mayastor-etcd, deleting a ReplicaSpec only where it had no owning volume and no live owner; then restart mayastor-agent-core so the control plane reloaded without the phantom, and confirm the pool no longer appeared in /v0/pools. THE GUARD tests/mayastor-retired.sh, modelled on tests/retired-crd-refs.sh, wired into tests/check.sh. Three halves, because a guard whose only success condition is "the scan matched nothing" passes vacuously the day someone deletes what it protects: 1. denylist — Mayastor's structural tokens, zero times, comments and CHANGELOG and docs excluded so accurate history does not fail the build. 2. allowlist — every survivor asserted by explicit non-zero COUNT: the ZFS driver, openebs-zfs in the egress denylist, Phase 3 and its openebs.io/nodeid selector, and all three reasons the pool is five workers. 3. dead paths — the deleted files must stay deleted, and the primitives must still exist. Verified by mutation, not by assumption: reintroducing a mayastor-* StorageClass, deleting the ZFS driver manifest, and renaming Phase 3 each turn it red. It also caught its own first draft passing vacuously, where a pattern beginning with `-` was read by grep as an option. CHECKS tests/check.sh exits 0. every-guard-has-a-caller reports 62 guards, 50 gated by CI. Every touched kustomization renders, with zero Mayastor references in the cluster and infrastructure trees. rules.yaml still holds five PrometheusRules and the Cilium policy still denies egress to openebs-zfs. Claude-Session: https://claude.ai/code/session_01MdSbMhzabSbpG8TtP9Ur3H