The coverage pages led with a percentage and an "x of y" count, and every
table listed the modelled operations Spinifex does not implement, which reads
as a scorecard against AWS rather than a statement of what the platform serves.
A published page now opens with the operation count alone, tables the
operations the gateway serves, and carries a separate not-applicable table with
each reason inline instead of footnotes. The unimplemented operations and the
counts move to docs/coverage/internal-report.md, which no docs-site slug points
at. A service with no implemented operations has no publishable page.
Elastic Load Balancing v2 API Coverage — Spinifex Docs
The Elastic Load Balancing v2 API operations Spinifex implements, for both the Application and Network Load Balancers it serves, with those it does not.
Coverage
overview
aws
compatibility
coverage
elbv2
load balancing
networking
ELBv2 API Coverage
Overview
Spinifex implements 34 operations in the ELBv2 2015-12-01 API model.
Two data planes
The data plane is a system-managed load balancer VM, launched automatically during CreateLoadBalancer. Application Load Balancers run HAProxy for the L7 surface — rules, fixed responses and redirects over HTTP and HTTPS. Network Load Balancers run nginx stream for the L4 surface — TCP, UDP, TLS and TCP_UDP — because HAProxy cannot load-balance UDP. The agent selects the engine from the configuration the control plane delivers, so the choice follows the load balancer type and is not separately configurable.
Julian Sommer
e2fb37c0ac