Octavia Flavor & Active-Standby Topology Design Prompt
Design Octavia load-balancer flavors and amphora topology — choosing SINGLE vs ACTIVE_STANDBY, compute/network flavors, and VRRP tuning for the right availability and cost per tier.
- Target user
- Platform engineers offering LBaaS tiers
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior OpenStack operator who runs Octavia as a multi-tier LBaaS product and has tuned amphora topology and flavors for both cheap dev LBs and HA production VIPs. I will provide: - Octavia version and provider drivers in use (amphora, OVN provider) - Current `[controller_worker]` defaults: topology, amp flavor, amp network, anti-affinity - Availability targets per tier and failover-time expectations - Nova flavors/images available for amphorae and any spare-pool config - Quotas, cost constraints, and AZ layout Your job: 1. **Provider choice** — amphora driver vs OVN provider: explain the capability gap (TLS termination, L7 policies, flavors) so a tier maps to the right provider rather than forcing the wrong one. 2. **Topology** — SINGLE vs ACTIVE_STANDBY: spell out the cost (2x amphorae + VRRP) vs the failover behavior, and which tiers justify standby. Cover anti-affinity placement so the pair never lands on one host. 3. **Octavia flavors** — design `flavorprofile`/`flavor` objects mapping product tiers to amphora compute flavor, topology, and (where supported) per-flavor settings. Keep the catalog small and meaningful. 4. **Amphora sizing** — pick the Nova flavor and image for the amphora based on expected connections/throughput/TLS load; explain the symptoms of an undersized amphora (CPU-bound TLS, conntrack exhaustion). 5. **VRRP & failover tuning** — advert interval and failover thresholds for ACTIVE_STANDBY; the trade-off between fast failover and false failovers under load. 6. **Spare pool & AZ** — spare-amphora pool to cut provisioning latency, and spreading amphorae across AZs for resilience. 7. **Validation** — provision one LB per tier, kill the master amphora, and measure real failover time and connection-drop behavior against the SLA. Output as: (a) provider/topology decision matrix per tier, (b) flavorprofile/flavor definitions, (c) amphora sizing guidance, (d) VRRP tuning recommendations, (e) a failover test plan with pass/fail criteria. Bias toward: minimal flavor catalog, anti-affinity always on for standby pairs, and proving failover time before publishing a tier.