feat: retire the five per-lane BuildKit daemons and the redundant classes #426
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/retire-per-lane-buildkits"
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
sean/binjovicutover is live: every lane dialsbinjovi-buildkit, all 20 agent pods mount the shared client certificate, and the Shipwright path has been building through it since the previous release. This deletes what they left behind.Gone: the admission and Release daemons (
buildkit-cache.yaml), the Zelnet package daemon, the IBM i RPG daemon, and the Shipwright daemon. Six caches holding 200Gi of claim become one holding 100Gi.Also gone:
zfs-buildkit-{32k,128k,1m}and thetank/buildkit-*datasets. They duplicatedzfs-nvme-*to make a recordsize comparison fair; that comparison belongs to purpose-built benchmark daemons on the existing classes, not to a parallel storage family carrying production caches. The datasets are left on the nodes — empty, harmless, andzfs destroyfrom a privileged DaemonSet running on every node is a foot-gun for one line of tidiness.Lane-specific egress followed the daemon rather than being deleted with it. The IBM i host ports and gibson TN3270 were only ever pinned by the per-lane guards, so those assertions now run against the shared daemon-s policy, from the lane guards, where a reader looks for a lane-s requirements. The RPG guard also fails if 9474 ever appears: the lane opens 9471-9473 and 9475-9476, and the gap is deliberate.
Guards rewritten rather than dropped.
binjovi-buildkit-cache.shandzfs-buildkit-classes.share deleted with what they covered.binjovi-package-native.shandbinjovi-ibmi-rpg-native.shkeep everything about identity and OAuth and lose only the daemon properties now pinned once inbinjovi-buildkit.sh.tests/binjovi.shholds an exact-diff inventory of the Binjovi kustomization, so it moves in the same commit or the suite fails — as it did, twice, which is the guard working.The tombstone refuses to delete a claim any pod still mounts. A mounted claim keeps the
pvc-protectionfinalizer, so the delete would hang to the deadline rather than fail; refusing up front says why.buildkitd-cache-1mis not in it — the Shipwright tree isprune: trueand Flux removes that one itself.https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76
The sean/binjovi cutover is live: every lane now dials binjovi-buildkit, all 20 agent pods mount the shared client certificate, and the Shipwright path has been building through it since the previous release. This deletes what they left behind. Gone: the admission and Release daemons (buildkit-cache.yaml), the Zelnet package daemon, the IBM i RPG daemon, and the Shipwright daemon. Six caches holding 200Gi of claim become one holding 100Gi. Also gone: zfs-buildkit-{32k,128k,1m} and the tank/buildkit-* datasets. They duplicated zfs-nvme-* to make a recordsize comparison fair; that comparison belongs to purpose-built benchmark daemons on the existing classes, not to a parallel storage family carrying production caches. The datasets are left on the nodes -- empty, harmless, and `zfs destroy` from a privileged DaemonSet running on every node is a foot-gun for one line of tidiness. Lane-specific egress FOLLOWED the daemon rather than being deleted with it. The IBM i host ports and gibson TN3270 were only ever pinned by the per-lane guards, so those assertions now run against the shared daemon's policy, in the lane guards, where a reader looks for a lane's requirements. The RPG guard also fails if 9474 ever appears: the lane opens 9471-9473 and 9475-9476, and the gap is deliberate. Guards rewritten rather than dropped. binjovi-buildkit-cache.sh and zfs-buildkit-classes.sh are deleted with what they covered. binjovi-package-native.sh and binjovi-ibmi-rpg-native.sh keep everything about identity and OAuth and lose only the daemon properties now pinned once in binjovi-buildkit.sh. tests/binjovi.sh holds an exact-diff inventory of the Binjovi kustomization, so it moves in the same commit or the suite fails -- as it did, twice, which is the guard working. The tombstone refuses to delete a claim that any pod still mounts. A mounted claim keeps the pvc-protection finalizer, so the delete would hang to the deadline rather than fail; refusing up front says why. buildkitd-cache-1m is not in it: the Shipwright tree is prune: true and Flux removes that one itself. Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA769e3a20d289f59299e7cf