deployment: manna on a persistent volume — the jar survives the restart
Manna was an emptyDir: every pod creation emptied it and the vessel sat unready until the kohen wrote the day's portion again. On 2026-10-04 that happened seven times in one day of rollouts. deploy/ARCHITECTURE.md has always specified a block-storage volume for it and manna-volume.yaml has always defined the claim; it was "not applied at Day 3" and stayed that way. - manna-volume.yaml: storageClassName exoscale-sbs (the cluster's only class is not marked default — without it the claim stays Pending), 1Gi. Applied; bound in 6 s. - deployment.yaml: the manna volume is the manna-pvc claim. `kubectl diff` against the live deployment showed this as the only change. - KOHEN.md: apply order (the claim before the pod), and the daily-ops note — write once a day, not once per restart. Verified on the live pod: manna written once onto the volume; then a rollout restart with NO provision written by anyone — the new pod was Ready and serving 49 s later, health 7/7, /peah/ask 200. What this does not change: the portion still expires by its own date and expires_at (Shemot 16:19-20). And the ledger is in memory — a restarted pod counts consumption from zero against the same day's allocation, as it always did; that is now reachable without the kohen's hand, and is recorded as open. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
1 parent
3eec60dbdb
commit
41a3e51a43
3 files changed
+21
-5
No files matched your search
@@ -23,7 +23,8 @@ spec:
|
||||
# (maxSurge 25% → 1 extra pod) asks for 450m CPU the node does not
|
||||
# have beside the running pod, and the rollout hangs Pending while the
|
||||
# old image keeps serving (tablet 31, 2026-10-04). Replace in place.
|
||||
# The new pod is not Ready until the kohen writes manna (emptyDir).
|
||||
# The new pod reads the day's manna from the manna-pvc volume; it is
|
||||
# Ready again without the kohen, as long as today's portion was written.
|
||||
strategy:
|
||||
type: RollingUpdate
|
||||
rollingUpdate:
|
||||
@@ -60,8 +61,11 @@ spec:
|
||||
# whose records land on a disk no one reads has not disposed of
|
||||
# anything; it has only stopped looking.
|
||||
volumes:
|
||||
# The day's portion, kept through a pod restart (manna-volume.yaml).
|
||||
# ReadWriteOnce is enough: one replica, replaced in place.
|
||||
- name: manna
|
||||
emptyDir: {}
|
||||
persistentVolumeClaim:
|
||||
claimName: manna-pvc
|
||||
# Shared /tmp for every container that speaks over it:
|
||||
# the Talmudic Unix socket (/tmp/shorashim/talmudic.sock) and
|
||||
# the azazel file bridge (/tmp/shorashim/azazel/pending_l3).
|
||||
|
||||
@@ -2,6 +2,16 @@
|
||||
# The kohen/treasurer writes today.json to this volume.
|
||||
# The vav_pipeline reads it. Provision is external to the system.
|
||||
# Shemot 16:4 — d'var yom b'yomo.
|
||||
#
|
||||
# Applied 2026-10-04. Until then the deployment mounted manna as an
|
||||
# emptyDir, so every pod creation emptied the jar and the vessel stayed
|
||||
# unready until the kohen wrote the day's portion again — seven times
|
||||
# in one day of rollouts. The portion still expires by its own date and
|
||||
# `expires_at` (Shemot 16:19-20); the volume keeps it through a restart,
|
||||
# it does not keep it past its day.
|
||||
#
|
||||
# storageClassName is explicit: the cluster's only class (exoscale-sbs)
|
||||
# is not marked default, and a claim without one stays Pending forever.
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
@@ -9,8 +19,9 @@ metadata:
|
||||
name: manna-pvc
|
||||
namespace: shorashim
|
||||
spec:
|
||||
storageClassName: exoscale-sbs
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 100Mi
|
||||
storage: 1Gi
|
||||
Reference in new issue
Block a user