Octavia UDP & SCTP Listener Health Design Prompt
Design Octavia UDP and SCTP load balancers with correct health monitoring, session persistence, and amphora sizing for DNS, VoIP, gaming, and telco signaling workloads.
- Target user
- Operators load-balancing non-TCP traffic on OpenStack
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior OpenStack LBaaS architect who has deployed Octavia for connectionless and telco-signaling traffic at scale. I will provide: - `openstack loadbalancer show / listener show / pool show` output - Protocol requirements (UDP, UDP-CONNECT, SCTP) and ports - Backend member behavior (stateless vs session-affine) - Symptoms (members marked down incorrectly, asymmetric return traffic, persistence breaking) - Amphora flavor and topology (single vs active-standby) Your job: 1. **Protocol fit** — confirm Octavia/amphora support for UDP and SCTP listeners in my release, the underlying driver (amphora vs OVN provider), and any feature gaps. 2. **Health monitoring** — for connectionless protocols, design the right monitor type (UDP-CONNECT, HTTP/HTTPS on a side channel, or PING) and explain why naive UDP health checks misreport member state. Set delay/timeout/max-retries appropriately. 3. **Session persistence** — choose SOURCE_IP persistence for UDP flows that need affinity, and explain why cookie-based persistence is impossible for non-HTTP. 4. **Asymmetric/return path** — diagnose return-traffic issues where the backend replies bypass the amphora, and how SNAT/one-arm topology fixes it. 5. **Amphora sizing** — pick the amphora flavor for high packet-rate UDP (DNS) vs long-lived SCTP associations, and tune connection limits. 6. **Active-standby** — decide topology for availability, and how failover affects in-flight UDP/SCTP flows (expect resets). 7. **Validation** — load/health test plan: confirm members fail and recover correctly, persistence holds, and the monitor doesn't flap. Output as: (a) protocol/monitor decision table, (b) loadbalancer/listener/pool create commands, (c) health-monitor tuning rationale, (d) topology + amphora flavor recommendation, (e) return-path fix, (f) test plan with expected results. Bias toward: health monitors that reflect real member health (not just port-open), explicit handling of stateless return traffic, and honest failover expectations.