claude-bot
e56f1e7cf6
Addresses the third blocking review finding on #504. The PR claimed the namespace move fixes wp-pg's absent metrics. It does not, on its own. Prometheus requires the `release: kube-prometheus-stack` label that CNPG's own enablePodMonitor omits, so every scraped cluster has a hand-written PodMonitor in apps/monitoring-rules/cnpg-podmonitors.yaml — ak-pg, im-pg, gf-pg, pprl-pg. There has never been one for wp-pg. So wp-pg was missing both halves: no scrape target configured, and no monitoring ingress allow in the apps baseline. Fixing the policy half was necessary but not sufficient, and the runbook's cnpg_collector_up check would have returned empty either way — unable to confirm the thing it existed to confirm. Adds the PodMonitor in the woodpecker namespace. Also from the review: - Added a ScheduledBackup for the restored cluster. Every other CNPG cluster here pairs isWALArchiver with one. Without it the new wp-pg-woodpecker prefix takes continuous WAL but never a base backup, so it has no independent recovery point and wp-pg-store's 30d retention has nothing to prune against — the WAL chain grows unbounded for as long as stage 1 sits before cutover. Scheduled 02:40, clear of the apps cluster's 02:35 and the other clusters' 02:30. - Documented that the `woodpecker` KS goes not-Ready while the restore runs. Its healthCheckExprs matches Cluster by GVK with no name qualifier, so Flux evaluates it against both the live apps/wp-pg and the restoring woodpecker/wp-pg, and wait: true makes the KS that owns production Woodpecker report unhealthy. Expected, does not cascade since nothing dependsOn it, but it would read as an outage without a note. - Dropped the app.kubernetes.io/name label from the new Namespace; no other namespace in that file carries one. Co-Authored-By: Claude Bot <claude-bot@renner.uno>