docs(nginx-routing): mark bluegreen sed bug fixed (devops#61)

Both deploy + rollback now parse the upstream from the map line and flip
only that line (address-scoped exact swap); the derived color table is
never touched. Note the failure was silent (standby healthy, traffic stays
on old container).

Session: 3

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-07-24 08:54:11 -04:00
parent 658340fa2e
commit 8f591edc8b
@@ -49,12 +49,17 @@ service is single-instance.
- **Never recreate the ACTIVE color to deploy** — that is a full outage for the service, not a
cutover. `scripts/bluegreen-deploy.sh <svc> <ver>` does the standby-only deploy + flip correctly;
use it. (A hand-deploy that recreated the active `incident` container caused a ~35-min fleet
outage on 2026-07-03 — see platform.deployment.)
outage on 2026-07-03 — see platform.deployment.) It parses the live upstream out of the map line
(so `devices` = `hiveiq-devices-backend-<color>` works) and flips only that line — `rollback` too.
- **Flip the SOURCE map line only — never a global search/replace of the color.** Each
`$<svc>_backend` has a derived `$<svc>_active_color` lookup map just below it; a global
`blue→green` sed corrupts that table (two identical keys). Target the line:
`sed -i '/\$<svc>_backend .*default/ s/-blue/-green/' 00-backends.conf`.
⚠️ `bluegreen-deploy.sh` currently uses a global sed and has this bug — flip by hand or fix the script.
✅ **Fixed 2026-07-24** (hiveiq-ops/hiveiq-devops#61): `bluegreen-deploy.sh` and
`bluegreen-rollback.sh` now flip only the `map $host $<key>_backend` line with an address-scoped
exact-string swap — the derived color table is never touched. (Before the fix both used a global
sed that corrupted it; the failure was silent — the standby comes up healthy and traffic stays on
the old container, so only a behaviour-level A/B catches it.)
- **Stale hardcoded hostnames = 502 on relative `/api/`.** Per-domain confs
(devices/incident/dashboard/aria) once pinned pre-blue/green hostnames and 502'd; resolved
2026-06-30 by moving them to the `map` vars. **If a domain 502s on `/api/` again, recheck this