1750b3b263ab196ddcf9feb0c9b1cf7998716650
Declared v1.36.58 against v1.36.68 running. This is the one that could have taken the chain down: zood-mv is the only luxd StatefulSet on RollingUpdate with podManagementPolicy Parallel, so a sync would not have rolled back gradually — it would have restarted all five Zoo validators at once, at an older version. Two facts make that unrecoverable rather than merely bad. luxd waits for peers before it listens, so a whole fleet restarting together deadlocks: every node is waiting for a node that is also waiting. And N=5 with alpha=4 means one node down is already a de-facto halt, so there is no slack to absorb it. The value is copied from the live StatefulSet. Nothing changes; the app simply stops carrying an instruction that would have been obeyed. Co-authored-by: Hanzo Dev <[email protected]>
Zoo Universe — retired
Read-only from here. Canonical: https://git.hanzo.ai/zoo/universe
This tip is an ancestor of canonical main, so no commit reachable from this
branch is unique to it — the canonical repo is a strict superset. Nothing was
lost by stopping here.
Two universes for one org is a split brain: a push lands somewhere real, reports
success, and never reaches a cluster, because CD reconciles the other one
(deploy/applicationset.yaml names the canonical URL). One repo per org means
that failure cannot happen.
Description
Declared state for the zoo fleet: one values file per service, one ApplicationSet
1.2 MiB
Languages
TypeScript
70.1%
Shell
21.5%
Makefile
8.4%