Azure / Azure/azure-functions-host
[Compute Separation][AH5+AH6A-M1] Validate the one-worker HTTP flow across container boundaries
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 36
Description
> **Parallel non-blocking validation.** This issue is outside `BYOC-M1`, is not a required sub-issue of #11965, and is not a prerequisite for #11965 or [internal BYOC #219](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/219). It is an optional pre-stamp contract oracle.
## Roadmap mapping
| Field | Value |
|---|---|
| Roadmap IDs | `AH5`, `AH6A` M1 subset |
| Lane | Aspire integration harness |
| Related Feature | #11965, non-blocking |
| Depends on | `AH4B`, `PR-M10+HB4A`, WorkerProxy image inputs |
| Blocks | Nothing |
| Related gates | HI4, G5a, WC1B |
## Why this PR exists
Re-run the AH4B flow with compute Host, WorkerProxy, real worker, and capacity receiver in separate containers on one shared network. This catches loopback/listener, DNS, port-reachability, and image-layout defects before a costly stamp cycle. Container topology and its management workflow stay together because neither produces evidence alone.
## Source material
- Roadmap AH5, AH6A, and G5a.
- Reference-only `tools/ComputeSeparation/AppHost` container mode, SampleIsolatedApp Dockerfile, MockWorker/FunctionsNetHost Dockerfiles.
- Product artifact contracts from PR-M10/HB4A and HP1.
- [internal BYOC #219](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/219), [internal BYOC #117](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/117), and [internal BYOC #123](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/123).
Do not port the prototype host.json bind mount, fixed credentials, production networking, Host RequestSlotsController, auth, or image-promotion logic.
## Current state
AH4B proves the full flow in project mode on one machine, which can hide loopback-only bindings and localhost assumptions. No current repository topology builds the compute artifact, WorkerProxy, unchanged worker, and a capacity receiver as peer containers.
## Proposed implementation
1. Add a `UseContainers` switch and container launch profile to the existing AppHost; project mode remains default.
2. Add compute Host container from PR-M10/HB4A inputs. Treat any harness-only image-layout deviation as a product issue finding, not a workaround.
3. Add WorkerProxy container from its Dockerfile with named management, runtime-gRPC, worker-gRPC, and HTTP-forwarding endpoints. Explicitly resolve whether the worker-facing listener must bind beyond loopback; record any product change as a finding.
4. Add one supported unchanged .NET isolated worker image with SampleIsolatedApp at the standard app path, addressed through WorkerProxy by container-network name. Record any all-interface HTTP-listener requirement as WC1B evidence rather than modifying the worker here.
5. Add a tiny harness-only fake appserver capacity receiver container; it observes revisions only and does not lease slots.
6. Use one Aspire-managed shared network and resource-name DNS; no hand-built production network simulation.
7. Reuse AH4B workflow/assertion code: assign -> ready/state -> link -> positive revision -> anonymous HTTP request -> `200` -> dual-leg terminal -> teardown.
8. Capture component-attributed, redacted evidence on failure.
9. Assert all containers and network stop cleanly and a second run succeeds without manual cleanup.
10. Extend build-only CI only. Container runs remain local/opt-in and non-required.
## Runtime-generated credentials
Generate all keys/tokens/storage credentials per run and inject as environment. Never bake credentials into images, Dockerfiles, launch settings, bind mounts, logs, or evidence. Sample trigger remains anonymous.
## Tests and evidence
- All four resources become ready and address each other by container name.
- Before link: ScriptHost not started and capacity zero.
- Assignment and link workflows are deterministic.
- Fake receiver observes zero, then one positive strictly increasing revision, then a higher zero revision on ineligibility.
- Anonymous HTTP request returns expected `200` across container boundaries; both legs terminate under one correlation ID.
- Project-mode parity uses the same assertions.
- Any image/listener/unchanged-worker deviation is filed against its owner rather than hidden in harness code.
- Teardown leaves no containers, network, volumes, or ports; two consecutive runs pass.
- HT14 standard and compute publish isolation evidence passes.
## Explicit exclusions
No real ACR/pool/stamp deployment, published-image validation, real appserver or Frontend slots, auth/TLS, customer host.json, drain/reconnect/failure matrices, multi-worker, billing, extension gRPC, Durable, assembly streaming, worker/SDK modification, broad diagnostics/performance, or required CI.
## PR stop condition
Stop when the container topology runs the complete one-worker M1 workflow automatically, returns anonymous HTTP `200` with both legs terminal, attributes failures, tears down cleanly/repeatably, preserves project-mode parity, and leaves standard product unchanged. Do not add production infrastructure, security, later lifecycle, or real appserver wiring.
Contributor guide
Assessment
This issue has not been assessed yet.