Hanzo AI
a9cf29e4c2
26e7154 moved the tag from v1.36.58 to v1.36.68 to stop this file declaring a version behind the fleet, and left the digest on v1.36.58's bytes. A reference carrying both resolves BY DIGEST, so the declaration it left behind was the one it set out to remove -- run .58, report .68 -- and now with the tag agreeing with the running fleet, nothing was left to notice it. That is the failure mode worth naming: a drifted pin does not fail, it succeeds at doing nothing. Both halves are now v1.36.68 (ebd16ed5…), read from the registry in one answer. The setup initContainer moves with them; it ran .58 by the same accident, and a node whose init and main containers are different builds is a question nobody should have to ask. Consequence, on this file specifically: zood-mv is the only luxd StatefulSet on RollingUpdate with podManagementPolicy Parallel, N=5 and alpha=4. A sync would have restarted all five Zoo validators together onto ten-releases-old bytes, and luxd waits for peers before it listens -- every node waiting for a node that is also waiting. 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.