# `veza_haproxy_switch` role

Atomically swap HAProxy's active color. Runs against the
`{{ veza_container_prefix }}haproxy` container after `veza_app` has
recreated + health-probed all three components in the inactive color.

## Why a separate role from `haproxy`?

- `roles/haproxy` provisions a fresh HAProxy container — install
  the package, lay down the *initial* config, enable the systemd
  unit. It runs once when the staging/prod env is bootstrapped and
  occasionally when the global config shape changes.
- `roles/veza_haproxy_switch` performs the *per-deploy* delta —
  re-template the cfg with a new `veza_active_color`, validate,
  swap, HUP. It runs once at the end of every successful deploy.

Splitting them keeps the per-deploy path narrow (no apt, no service
install) and lets `roles/haproxy` remain idempotent when the global
shape hasn't changed.

## Inputs

| variable                | required | meaning                                                              |
| ----------------------- | -------- | -------------------------------------------------------------------- |
| `veza_active_color`     | yes      | Color to switch TO (`blue` or `green`). Becomes the new active.      |
| `veza_release_sha`      | yes      | SHA being deployed. Logged in the active-color history file.         |
| `veza_container_prefix` | inherit  | From group_vars/<env>.yml.                                           |
| `haproxy_topology`      | inherit  | Should be `blue-green` for this role to make sense.                  |

## Failure semantics

The render → validate → atomic-swap → HUP sequence runs in an
Ansible `block:` with a `rescue:` that restores `haproxy.cfg.bak`
(captured before the swap) and re-HUPs. So an invalid config or a
HUP failure leaves HAProxy serving the *previous* active color
exactly as before — the deploy as a whole then fails on the playbook
level.

## What the role does NOT do

- It does not destroy or recreate the HAProxy container. That's a
  one-time operation under `roles/haproxy`.
- It does not touch app containers — by the time this role runs,
  blue/green app containers are both healthy.
- It does not remove the previously-active color's containers. They
  survive (intentional) so a rollback can flip back instantly. The
  next deploy naturally recycles them.