Azure / Azure/azure-functions-host

[Compute Separation][AH5+AH6A-M1] Validate the one-worker HTTP flow across container boundaries

Open
#11,978 0 comments 0 reactions 1 assignee Claimed by @brettsam View on GitHub
compute-separation
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.