docs(demos): expand cloud burst resilience example - #18
Merged
nerdalert merged 1 commit intoAug 31, 2026
Merged
Conversation
|
PR too large: 1913 lines added (limit: 750, excludes Cargo files, tests, docs, examples, and benchmarks). Please split into smaller PRs. Add |
Signed-off-by: Brent Salisbury <bsalisbu@redhat.com>
nerdalert
force-pushed
the
feat/cloud-burst-resilience-demo
branch
from
August 31, 2026 13:33
0cc9b85 to
1118a1c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This expands the Grid cloud-burst demo into a complete regional resilience and multi-cloud overflow example.
The demo now follows inference requests across two consumer gateways, two provider sites, four local llm-d simulators, and an external overflow group containing Azure OpenAI and OpenAI. It demonstrates
healthy regional balancing, progressive backend failure, cross-site fallback, pressure-driven admission, cloud overflow, recovery, shared sliding-window soft quotas, and exact request attribution.
A new recording is included at the top of the README.
User stories
As an inference-platform operator, I want requests to remain on healthy site-local capacity, fail over to another Grid site when necessary, and use external providers only when the local fleet cannot accept
new work.
As a reliability engineer, I want backend failure and queue pressure to produce distinct, explainable admission states.
As an application owner, I want one shared token allocation to follow my workload across gateways and provider changes.
As an operator investigating a request, I want to see the consumer gateway, provider boundary, selected inference backend or cloud route, quota decision, and upstream HTTP result.
Demonstrated behavior
existing_only; new traffic uses overflow.Resilience model
The demo makes the fallback order explicit:
Backend failure and queue pressure remain separate conditions. Failed endpoints are withdrawn through health reconciliation, while healthy but pressured providers remain available for existing work and reject
only new admission.
Grid computes and publishes these transitions asynchronously. Praxis continues serving from its last accepted routing snapshot and switches only after a newer revision has been validated and loaded. There is
no synchronous Grid or Kubernetes lookup on the request path.
Multi-cloud overflow
Azure OpenAI and OpenAI participate in the same external provider group, with round-robin selection inside that group.
The documentation includes:
The recording includes an Azure-attributed HTTP 429. This is identified as an upstream Azure limit, not a Praxis quota denial. A Praxis denial occurs before provider routing and has no provider hop.
Quota behavior
The consumer gateways share application/model sliding-window state through Valkey.
Each demo application has an independent rolling token allocation. Tokens are reserved before provider selection and reconciled against actual response usage afterward. Because the quota key is independent of
the selected provider, regional failover and cloud overflow do not reset or duplicate the application allowance.
The recorded policy uses soft enforcement, so over-allocation remains visible without turning every overage into a pre-provider rejection.
Documentation and resources
The README now includes:
New declarative resources cover:
Diagnostic and qualification scripts cover Azure validation, queue pressure, backend withdrawal, request stalls, single-provider latency, and the full cloud-burst matrix.
Scope and limitations
This remains an early work-in-progress demonstration assembled from development branches while the underlying contracts are finalized upstream.
It demonstrates group fallback rather than gradual percentage-based bursting or cost-aware placement. Example spend values are illustrative and are not billing records. External providers retain their own
independent quotas, rate limits, and availability.
Reproducing the environment may require manual integration work and familiarity with Kubernetes, Grid, Praxis, external-provider credentials, and the referenced development branches.
Related work