CSP API Rate Limiting#
CB-Tumblebug enforces per-CSP and global concurrency limits when performing bulk operations — primarily spec fetching and resource registration — to stay within cloud provider API rate limits. The configuration is centralized in src/core/model/csp/csp.go and consumed by the bulk operation logic in src/core/resource/spec.go.
Configuration: RateLimitConfig#
The RateLimitConfig struct captures three categories of limits per CSP:
| Field | Purpose |
|---|---|
MaxConcurrentRegistrations | Max parallel connections during resource registration |
RegistrationDelayMinMs / RegistrationDelayMaxMs | Stagger delay range to prevent API bursts |
MaxConcurrentRegions / MaxNodesPerRegion | VM creation parallelism |
MaxConcurrentRegionsForStatus / MaxNodesPerRegionForStatus | VM status fetch parallelism |
A global cap of GlobalMaxConcurrentConnections = 10 applies across all CSPs simultaneously.
Per-CSP values are looked up via GetRateLimitConfig(providerName), which resolves derived CSP names (e.g., openstack-new01 → openstack) before table lookup. Unknown CSPs fall back to a conservative default (MaxConcurrentRegistrations=3, delays 1000–3000ms).
Per-CSP Limits at a Glance#
| CSP | MaxConcurrentRegistrations | Delay Range (ms) | MaxConcurrentRegionsForStatus | Notes |
|---|---|---|---|---|
| AWS | 5 | 500–2000 | 10 | — |
| Azure | 4 | 500–2000 | 8 | — |
| GCP | 4 | 1000–3000 | 12 | — |
| Alibaba | 3 | 1000–3000 | 6 | Strict API; see below |
| Tencent | 2 | 2000–5000 | 6 | Hard 10 req/sec limit |
| IBM | 3 | 500–2000 | 10 | — |
| NCP | 2 | 1000–3000 | 3 | Strictest infra limits |
| NHN | 2 | 1000–3000 | 5 | — |
| KT | 2 | 1000–3000 | 10 | — |
| OpenStack | 3 | 500–2000 | 5 | — |
Bulk Spec Fetching: Two-Level Semaphore#
fetchSpecsForAllConnConfigsInternal uses a two-level concurrency model:
- Provider goroutine — one goroutine per CSP provider, all run in parallel.
- Connection semaphore — within each provider, a buffered channel limits concurrent connections :
- Default: 50 concurrent connections per provider
- Alibaba override: 5 — empirical testing showed concurrency ≥10 causes ~90% timeout on
DescribeAvailableResource
Each connection task runs with a 20-minute timeout. Capacity test results are inline in the code comments :
| CSP | Connections tested | Parallel result |
|---|---|---|
| AWS | 28 | All OK (~8.8s) |
| GCP | 42 | All OK (~3.2s) |
| Azure | 46 | All OK (~100s) |
| Tencent | 16 | All OK (~11.0s) |
| IBM | 11 | All OK (~8.5s) |
| Alibaba | 29 | Limited to 5 |
Price Fetching: Three-Level Concurrency#
Bulk price fetching in spec.go adds a third layer :
- Provider-level: max 3 providers processed simultaneously via semaphore
- Per-provider connection-level: 8 concurrent connections for GCP and Azure; 8 for AWS; configurable for Alibaba (
TB_ALIBABA_REGION_CONCURRENCY, default 10) - Spider path: 15 concurrent connections for all other providers
Alibaba: Dedicated Rate-Limit Handling#
Alibaba has the most complex rate-limit handling, in src/core/csp/alibaba/price.go:
- Worker pool: default 5 goroutines (
TB_ALIBABA_PRICE_WORKERS) - Per-call delay: 200ms between
DescribePricecalls (TB_ALIBABA_PRICE_INTERVAL_MS) - Retry with backoff: up to 3 retries (
TB_ALIBABA_PRICE_MAX_RETRY), base 1200ms backoff + jitter, triggered onErrorCode: ThrottlingorTooManyRequests - Transient network retry: single retry for connection reset, I/O timeout, TLS handshake timeout, EOF
Adding a New CSP#
To configure rate limits for a new provider :
- Add a name constant to
csp.goand append it toAllCSPs. - Add a
RateLimitConfigentry torateLimitConfigswith appropriate limits. - If the CSP is a derived instance (e.g., private OpenStack), call
RegisterCloudPlatformat startup so it resolves to the base platform's config.