sean/seanfarm
Watch
1
0
Fork
You've already forked seanfarm
 0
Code Issues Pull requests Projects Releases 400 Packages Wiki Activity

feat(storage): move the BuildKit caches onto the zfs-buildkit-* classes #410

Merged
binjovi-bot merged 1 commit from feat/buildkit-caches-on-uniform-classes into trunk 2026-09-07 14:06:18 +00:00
Conversation 0 Commits 1 Files changed 11 +226 -23
sean commented 2026-09-07 13:47:14 +00:00
Owner
Copy link

The classes landed in #404 with no consumers. This puts every surviving BuildKit cache on one:

class claim size
zfs-buildkit-32k binjovi-buildkit-ibmi-rpg-cache-32k 10Gi
zfs-buildkit-128k binjovi-buildkit-cache-128k 50Gi (control)
zfs-buildkit-1m binjovi-buildkit-package-cache-1m 50Gi
zfs-buildkit-1m shipwright-build/buildkitd-cache-1m 30Gi

128k is the control — the recordsize these caches already ran on. ibmi-rpg to 32k (RPG source is many small files), package and the kernel daemon to 1M (large mostly-sequential artifacts).

Be honest about what this measures. Four daemons building four different things is a daemon-x-recordsize observation, not a controlled experiment. It costs nothing and gives real-world signal; a controlled number needs a fixed Containerfile run against each daemon from cold.

The claims are renamed, not edited. storageClassName is immutable, so Flux must delete and recreate the claim — and the running daemon holds the kubernetes.io/pvc-protection finalizer, so that delete blocks indefinitely and the recreate then fails with AlreadyExists. force: true on the Kustomization is the same delete and deadlocks identically, which is why the plan-s original force-based approach was abandoned. A new NAME is a new object: Flux creates it, the Deployment-s Recreate strategy swaps the pod onto it. The suffix names the class, which is what this comparison is about.

The three orphaned Binjovi claims get a tombstone (that tree is prune: false); each Job waits until the live Deployment and its pods are on the new claim before deleting the old one, so an interrupted rollout cannot destroy a volume still in use. Shipwright is prune: true and needs none.

Caches start cold. They are caches. The admission and release claims are untouched — both daemons retire with the sean/binjovi cutover.

https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

The classes landed in #404 with no consumers. This puts every surviving BuildKit cache on one: | class | claim | size | |---|---|---| | `zfs-buildkit-32k` | `binjovi-buildkit-ibmi-rpg-cache-32k` | 10Gi | | `zfs-buildkit-128k` | `binjovi-buildkit-cache-128k` | 50Gi **(control)** | | `zfs-buildkit-1m` | `binjovi-buildkit-package-cache-1m` | 50Gi | | `zfs-buildkit-1m` | `shipwright-build/buildkitd-cache-1m` | 30Gi | 128k is the control — the recordsize these caches already ran on. ibmi-rpg to 32k (RPG source is many small files), package and the kernel daemon to 1M (large mostly-sequential artifacts). **Be honest about what this measures.** Four daemons building four different things is a daemon-x-recordsize observation, not a controlled experiment. It costs nothing and gives real-world signal; a controlled number needs a fixed Containerfile run against each daemon from cold. **The claims are renamed, not edited.** `storageClassName` is immutable, so Flux must delete and recreate the claim — and the running daemon holds the `kubernetes.io/pvc-protection` finalizer, so that delete blocks indefinitely and the recreate then fails with AlreadyExists. **`force: true` on the Kustomization is the same delete and deadlocks identically**, which is why the plan-s original force-based approach was abandoned. A new NAME is a new object: Flux creates it, the Deployment-s Recreate strategy swaps the pod onto it. The suffix names the class, which is what this comparison is about. The three orphaned Binjovi claims get a tombstone (that tree is `prune: false`); each Job waits until the live Deployment **and** its pods are on the new claim before deleting the old one, so an interrupted rollout cannot destroy a volume still in use. Shipwright is `prune: true` and needs none. Caches start cold. They are caches. The admission and release claims are untouched — both daemons retire with the `sean/binjovi` cutover. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76
feat(storage): move the BuildKit caches onto the zfs-buildkit-* classes
All checks were successful
binjovi/ci Binjovi completed the frozen plan
Details
c777b55d2d
 
The classes landed in 097b9d95 with no consumers. This puts every surviving
BuildKit cache on one, so the recordsize comparison has real build traffic:

  zfs-buildkit-32k   binjovi-buildkit-ibmi-rpg-cache-32k    10Gi
  zfs-buildkit-128k  binjovi-buildkit-cache-128k            50Gi   (control)
  zfs-buildkit-1m    binjovi-buildkit-package-cache-1m      50Gi
  zfs-buildkit-1m    shipwright-build/buildkitd-cache-1m    30Gi

128k is the control: it is the recordsize these caches already ran on. ibmi-rpg
goes to 32k because RPG source is many small files; package and the kernel
daemon go to 1M because both handle large mostly-sequential artifacts. Be
honest about what that measures: four daemons building four different things is
a daemon-x-recordsize observation, not a controlled experiment. It costs
nothing and gives real-world signal; a controlled number needs a fixed
Containerfile against each daemon from cold.

THE CLAIMS ARE RENAMED, NOT EDITED. storageClassName is immutable, so Flux must
delete and recreate the claim -- and the running daemon holds the
kubernetes.io/pvc-protection finalizer, so that delete blocks indefinitely and
the recreate then fails with AlreadyExists. `force: true` on the Kustomization
is the same delete and deadlocks the same way, which is why the plan's original
force-based approach was abandoned. A new NAME is a new object: Flux creates
it, the Deployment's Recreate strategy swaps the pod onto it, done. The suffix
names the class, which is exactly what this comparison is about.

The three orphaned Binjovi claims get a tombstone; that tree is prune: false.
Each Job waits until the live Deployment AND its pods are on the new claim
before deleting the old one, so an interrupted rollout cannot destroy a volume
still in use. Shipwright is prune: true and needs no tombstone.

Caches start cold. They are caches.

The admission and release claims are untouched: both daemons are retiring once
the sean/binjovi cutover lands, so moving them would be churn.

Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sean/seanfarm!410
No description provided.