Repository navigation
test: overlap shared service provisioning and Windows pod checks - #9813
Merged
Merged
Conversation
Create shared subnets sequentially before provisioning Bastion and Firewall concurrently. Run independent Windows pod checks concurrently and leave abandoned subnet cleanup to external GC. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 870cca72-7850-484f-8639-762022eceb16
Contributor
Windows Unit Test Results 3 files 18 suites 1m 7s ⏱️ Results for commit 6eb77f1. |
Contributor
Contributor
|
Contributor
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
Concurrent Azure service provisioning on the shared VNet still needs live validation and human review.
No open issues 🎉
What changed in this PR
Reduces E2E setup and Windows validation waits by extending shared concurrency patterns from #9806. Production provisioning and VHD behavior are unchanged.
Changes:
- Provisions Bastion and Firewall concurrently after sequential subnet setup.
- Runs Windows pod checks concurrently, preserving retries and error aggregation.
- Removes eager orphan-subnet cleanup and documents external cleanup ownership.
| File | Description |
|---|---|
| e2e/scenario/shared_infra.go | Overlaps service provisioning and removes orphan-subnet cleanup. |
| e2e/scenario/provision.go | Runs Windows pod checks concurrently. |
| e2e/README.md | Documents concurrency and subnet cleanup ownership. |
Review effort: Balanced
Tim Wright (timmy-wright)
approved these changes
Oct 18, 2026
Artur Khantimirov (r2k1)
enabled auto-merge (squash)
October 18, 2026 20:26
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.
What this PR does / why we need it:
Create/reuse shared subnets sequentially, then provision Bastion and Firewall concurrently. Run Windows Server Core and Nano Server pod checks concurrently, retaining retries, node placement, cleanup, and error aggregation.
Remove eager orphan-subnet cleanup: an empty subnet without an AKS cluster can belong to another runner still creating its cluster. External resource-group GC owns abandoned-resource cleanup.
VHD selection/replication and Linux pod validation are unchanged. No new helpers or test-file changes.
Local validation after rebasing onto main (from
e2e/):go test ./scenario ./toolkit— passed.go build ./...— passed.go test -race ./scenario ./toolkit— passed before rebase; the rebase preserved the patch unchanged.git diff --check— passed.Live Azure E2E validation was not run. Cold-run evidence suggests potential savings of about 8 minutes from shared service overlap and about 2 minutes per Windows lane from pod overlap; these are theoretical bounds, not measured improvements. Concurrent startup can contend for resources.
Scope: E2E framework only. Concurrency changes are reversible; subnet cleanup remains the external GC's responsibility.
Which issue(s) this PR fixes:
N/A. Follow-up to #9806.