RFC 0029: native Azure Blob storage - #440
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| This is the reproducible source prompt for | ||
| `0029-azure-reference-architecture.png`. It follows the target-platform diagram | ||
| workflow from `msftse/azure-architecture-proposal` and is intentionally limited | ||
| to the first supported public-cloud topology in RFC 0029. |
There was a problem hiding this comment.
🟡 New documentation cites a source that outside readers cannot open
The committed diagram note points readers to a workflow source that is not publicly reachable (msftse/azure-architecture-proposal at docs/rfcs/assets/0029-azure-reference-architecture.prompt.md:5), so an outside contributor cannot verify or reproduce the referenced procedure.
Impact: Readers outside the authoring organization hit a dead-end reference when trying to reproduce the architecture figure.
Documentation audience-neutrality rule in AGENTS.md
AGENTS.md maintenance rule 5 ("Keep docs audience-neutral") requires stable public identifiers over organization-specific labels, and says internal context should be translated into a durable public rationale before committing. The PR description itself acknowledges the workflow repository "is not publicly reachable to an unauthenticated upstream reviewer". Since the prompt text below it is already fully self-contained, the private-repo attribution can be dropped or rephrased as a neutral description of the method.
| This is the reproducible source prompt for | |
| `0029-azure-reference-architecture.png`. It follows the target-platform diagram | |
| workflow from `msftse/azure-architecture-proposal` and is intentionally limited | |
| to the first supported public-cloud topology in RFC 0029. | |
| This is the reproducible source prompt for | |
| `0029-azure-reference-architecture.png`. It follows a target-platform | |
| architecture-diagram prompt workflow and is intentionally limited | |
| to the first supported public-cloud topology in RFC 0029. |
Was this helpful? React with 👍 or 👎 to provide feedback.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
1 participant
Summary
Proposes RFC 0029 for native Azure Blob Storage support through canonical
az://<container>/<prefix>roots, the existing Lance + Apache Arrowobject_storeseams, and managed identity.The RFC also defines a reference Azure Container Apps deployment. Importantly,
it does not treat
minReplicas = maxReplicas = 1as a correctness lock:Azure may temporarily pre-warm extra replicas. Instead, every supplied server
and bootstrap writer must pass through one fail-closed PID-1 admission path:
Tini forwards signals and subreaps descendants while its supervised wrapper
owns an infinite per-cluster Blob lease before an OmniGraph child can start.
This is explicitly scoped as a cooperative process-admission mutex, not
engine-level data fencing or multi-writer support.
Architecture
The image was produced and visually reviewed with the
msftse/azure-architecture-proposaldiagram workflow. Its exactreproducible prompt
is committed beside the PNG. The workflow repository is not linked because it
is not publicly reachable to an unauthenticated upstream reviewer.
Why this PR is RFC-only
This follows OmniGraph's public-contribution sequence:
The implementation prototype, deployment package, CI job, docs, and validation
record are intentionally excluded from this branch.
Prototype evidence and evidence boundary
A prototype based on upstream
c62829acc6f5414356304d1c240d95fad38b8984has already passed:Lance data below the same cluster root;
anonymous Blob access disabled, container-scoped Blob RBAC, immutable ACR
image, authenticated mutation/query, restart persistence, physical Blob
inspection, retained-log credential scanning, and confirmed resource-group
cleanup.
That first live run proves the native storage and identity path. It does not
prove the newly specified lease-admitted mutable topology. The RFC therefore
requires a second adversarial live-Azure gate before an implementation PR may
claim support: competing app/job writers, unique lease IDs, lost responses,
graceful long-write drain, unexpected exit, hard-kill stuck-lease behavior,
one-child interval evidence, and explicit break-glass recovery.
Checks for this RFC branch
bash scripts/check-agents-md.sh— 74 links / 69 docs OKgit diff --check— cleanresource names or endpoint URLs, tokens, or proof-row values included
Requested feedback
az://<container>/<prefix>model fit OmniGraph's storageand URI contracts?
enforcement of the existing one-live-writer-process support boundary for the
first Container Apps reference?
before the separate implementation PR?
Greptile Summary
RFC 0029 proposes canonical Azure Blob roots, managed-identity authentication, and a Container Apps deployment that admits one writer through an infinite Blob lease.
az://<container>/<prefix>URI and storage semantics.Confidence Score: 4/5
The RFC is not ready to merge because its mandatory single-writer admission mechanism still lacks an implementable lease client within the stated dependency constraints.
The wrapper must perform Azure Blob lease operations, but the RFC assigns storage access to abstractions that expose no lease API while continuing to exclude a new Azure SDK or otherwise naming an implementation owner.
Files Needing Attention: docs/rfcs/0029-azure-blob-storage.md
Important Files Changed
Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart LR Clients[Clients] -->|HTTPS| Server[OmniGraph server] Job[Bootstrap job] --> Gate[PID-1 admission wrapper] Server --> Gate Gate -->|Acquire infinite lease| Lease[(Admission lease Blob)] Gate -->|Admitted child| Root[(Azure cluster root)] Identity[Managed identity] -.-> Lease Identity -.-> RootReviews (3): Last reviewed commit: "docs(rfc): specify PID 1 supervision" | Re-trigger Greptile