HAProxy was rejecting the cfg at parse time because every
`server backend-{blue,green}.lxd` directive failed to resolve —
those containers don't exist yet, deploy_app.yml creates them
later. The validate said :
could not resolve address 'veza-staging-backend-blue.lxd'
Failed to initialize server(s) addr.
Two complementary fixes :
1. Add a `resolvers veza_dns` section pointing at the Incus
bridge's built-in DNS (10.0.20.1:53 — gateway of net-veza).
`*.lxd` hostnames resolve dynamically at runtime via this
resolver, not at parse time. Containers spun up later by
deploy_app.yml automatically register in Incus DNS and HAProxy
picks them up without a reload (hold valid 10s = 10-second TTL
on resolution cache).
2. `default-server ... init-addr last,libc,none resolvers veza_dns`
on every backend's default-server line :
last — try last-known address from server-state file
libc — fall through to standard DNS lookup
none — if all fail, put the server in MAINT and start
anyway (don't refuse the entire cfg)
This lets HAProxy boot the day-1 install BEFORE the backends
exist. Once deploy_app.yml lands them, the resolver picks them
up within 10s.
Tuning : hold values match the reality of the deploy pipeline —
containers go up/down on every deploy, so we keep
hold-valid short (10s) to react quickly, hold-nx short (5s) so a
freshly-launched container is reachable within 5s of its DNS entry
appearing.
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
d9896686bd