hanzo-dev 8ae23fcf21 drop the grafana in ns monitoring
It reads from `prometheus.monitoring.svc:9090`, which does not exist on this
cluster -- so the panel has been a second lens onto nothing. Zoo's telemetry
goes to o11y over OTLZ, and one lens is the point.

It also carried `GF_SECURITY_ADMIN_PASSWORD: admin` beside
`GF_AUTH_ANONYMOUS_ENABLED: true`, in the clear, in a file in the repo. No
ingress pointed at it, so the exposure was in-cluster only, but "no route today"
is not a control.

Its 256Mi is what the otel-agent rollout on zoo-nodes-3mm2zq has been waiting
for: that node is at 99% of allocatable, the agent asks 192Mi, and a DaemonSet
rolling update stalls the whole set on one unschedulable pod.
2026-09-03 21:32:49 -07:00
2026-07-26 10:16:32 -07:00
2026-09-03 21:32:49 -07:00
2026-08-03 21:02:21 -07:00
2026-09-03 21:28:37 -07:00
2026-09-03 11:04:58 -07:00
2026-08-03 21:02:21 -07:00
2026-02-14 05:27:03 -08:00
2026-08-03 21:02:21 -07:00
2026-03-26 22:45:36 -07:00

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.

S
Description
Declared state for the zoo fleet: one values file per service, one ApplicationSet
Readme
1.2 MiB
Languages
TypeScript 70.1%
Shell 21.5%
Makefile 8.4%