Files
universe/deploy/lux-mainnet/graph-ipfs.yaml
T
zeekayandHanzo Dev 95f33a1b5d deploy: Recreate for the four RWO singletons, and stop two indexers dropping to uid 0
Both defects were found by watching a sync rather than by reading a file.

RWO + RollingUpdate is a rollout that never finishes. status and elastic parked on
"Multi-Attach error for volume … Volume is already used by pod(s) …" — the new pod
cannot attach a ReadWriteOnce volume the old one still holds, and maxUnavailable
keeps the old pod alive, so the surface stays UP while the rollout hangs
indefinitely. That reads as a healthy service with a pending change, which is the
worst shape a stuck deploy can take. Recreate costs one bounded restart and
completes. Applied to every values file in the fleet matching single-replica + an
RWO claim: lux-bridge/kv, lux-mainnet/graph-ipfs, lux-system/status, team/elastic.
The dead rollingUpdate keys go with it — under Recreate they are config that looks
set and is read by nothing.

lux-mainnet/lux-indexer and lux-testnet/lux-indexer lost pod
securityContext.runAsUser/runAsGroup 65532 to the last-applied prune described in
the previous commit, i.e. they are declared to run as root now. Both are
replicas: 0, so it is latent rather than live — which is exactly why it would have
shipped unnoticed the day someone scaled one up. podSecurityContext added, same
correction as their lux-devnet sibling.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-29 18:50:40 -07:00

43 lines
1.1 KiB
YAML

# Generated from the live lux-mainnet/graph-ipfs Deployment on do-sfo3-lux-k8s
# by hack/live2values.py. Live is the source: a repo of hand-applied
# manifests has unknown currency, the running fleet does not.
replicas: 1
selectorLabels:
app: graph-ipfs
containerName: ipfs
image:
repository: ipfs/kubo
tag: v0.28.0
pullPolicy: IfNotPresent
resources:
limits:
cpu: 500m
memory: 1Gi
requests:
cpu: 100m
memory: 256Mi
volumeMounts:
- mountPath: /data/ipfs
name: data
ports:
- containerPort: 5001
name: api
- containerPort: 8080
name: gateway
volumes:
- name: data
persistentVolumeClaim:
claimName: graph-ipfs-data
topologySpread:
enabled: false
lifecycle: null
terminationGracePeriodSeconds: 30
defaultReadinessProbe: false
imagePullSecrets: []
# RWO volume + one replica: Recreate, not RollingUpdate. A rolling update
# guarantees an overlap, the new pod cannot attach a ReadWriteOnce volume the
# old one holds, and the rollout parks on Multi-Attach forever while the old
# pod keeps serving — measured on status and elastic. Recreate costs one
# bounded restart and completes.
strategy: Recreate