Proposal: native Azure Blob storage and a safe Azure Container Apps deployment

[roy2392]

Problem

I want to run OmniGraph as the backend for an Azure-hosted company knowledge
graph and be able to give enterprise customers a maintained, reproducible Azure
path. Today the documented remote backend is S3-compatible object storage. An
Azure operator can add another S3-compatible service or mount Azure Files, but
neither provides a native managed-identity-to-Blob deployment or proves that
both OmniGraph control objects and Lance datasets use the same Azure substrate.

Proposed supported boundary

• Add one canonical storage URI: az://<container>/<prefix>. The storage
  account and credentials stay in the standard Azure environment contract.
• Use the Azure features already present in Apache Arrow object_store and
  Lance; do not add a second storage engine, manifest format, or Azure SDK.
• Use real Blob ETags for conditional create/update and fail closed if a
  conditional backend omits an ETag.
• Make managed identity the certified production path. The reference
  deployment scopes Storage Blob Data Contributor to one container and
  AcrPull to one registry; Storage shared keys and ACR admin/anonymous pull
  are disabled.
• Provide an Azure Container Apps reference with a one-replica sizing target,
  but do not treat that target as a lock. Azure explicitly permits temporary
  extra replicas during platform maintenance. The app, bootstrap job, retries,
  and every supplied writer path therefore enter through one PID-1 wrapper that
  must acquire a canonical, infinite Azure Blob lease before it starts an
  OmniGraph child.
• Treat that lease as a cooperative process-admission mutex, not an engine
  fencing token. Every wrapper uses a unique random proposed lease ID; a lost
  acquire response must be positively resolved with that exact ID before any
  child starts. Graceful shutdown drains the complete child process group
  before exact-ID release; a hard kill or unresolved response leaves the lease
  stuck and the replacement unready. The deployment never auto-breaks it.
  Explicit recovery freezes admissions, closes ingress, enumerates every
  revision and execution until process count is stably zero, and hard-fences an
  old runtime whose death cannot be proved before it breaks the lease.
• Keep multi-process writers, Azure Files, Key Vault-backed server admission,
  private-endpoint/VNet variants, sovereign clouds, and abfs:// aliases out of
  the initial support claim.

Evidence from a working prototype

I prepared the RFC and implementation locally, but I am intentionally not
opening an implementation PR before this design is accepted.

The prototype currently has:

• Azure URI/parser and storage-contract coverage;
• graph init/load/query/mutate/reopen against Azurite;
• Azure cluster import/apply/serve/evolve/delete coverage;
• direct az:// graph and config-free bare-az:// cluster HTTP tests;
• a PR-time Azurite job that rejects skipped cells and inspects the raw Blob
  layout for the state ledger, graph manifest, and Lance data beneath one
  cluster root, plus the checked-in branch-protection update that makes that
  context required once maintainers apply the policy;
• Bicep for Storage, a private container, ACR, managed identity/RBAC, Log
  Analytics, a Container Apps environment, a manual bootstrap job, and a
  single-replica-target HTTPS app;
• non-destructive template validation and a deployment proof script that checks
  authentication, topology, physical Blob objects, retained-log credential
  hygiene, and persistence across a replacement replica;
• a visually reviewed Azure reference-architecture PNG plus its reproducible
  msftse/azure-architecture-proposal prompt, with the lease-admitted child
  boundary shown separately from the one-replica sizing target.

On 2026-08-04 I ran the storage and managed-identity prototype from upstream base
c62829acc6f5414356304d1c240d95fad38b8984 in a disposable Azure public-cloud
resource group. ACR produced the immutable image digest
sha256:90fc54958d5278dca571b9106a1e795a5511add1bf24a257365011838d2837cb.
The managed-identity bootstrap succeeded, authenticated mutation/query passed,
Azure replaced the serving replica, and the replacement returned the value
written before restart from Blob Storage. A raw managed-identity Blob listing
found the cluster ledger, __manifest/_versions/*.manifest, and Lance
data/*.lance objects. The final RBAC scope was the single container; retained
bootstrap/app logs contained neither the exact bearer token nor credential
patterns. Azure then confirmed deletion of the disposable resource group. The
repository-ready validation record is redacted and contains no tenant,
subscription, resource name, URL, token, or proof-row value.

That run proves the native Blob path, managed identity, authorization, physical
layout, and restart persistence. It does not by itself certify the mutable
Container Apps topology: final review caught that maxReplicas = 1 is only a
target and platform maintenance may pre-warm an overlapping replica. The RFC
now requires the infinite-lease admission wrapper above, plus a second
adversarial live run covering simultaneous app/job contenders, graceful drain,
hard-kill stuck-lease behavior, ambiguous responses, and one-child interval
evidence before an implementation PR can claim supported mutable hosting.

Questions for maintainers

1. Does az://<container>/<prefix> fit OmniGraph's URI and storage model, with
   the account deliberately supplied through environment configuration?
2. Is the fail-closed infinite Blob lease wrapper an acceptable way for the
   Container Apps reference to externally preserve OmniGraph's current
   one-live-writer-process boundary, with replica count treated only as sizing?
3. Are there acceptance gates or Azure environments you want added or removed
   before I open the public RFC PR?

I have drafted RFC 0029, “Native Azure Blob storage,” and will link this
Discussion from it. After the RFC is merged (accepted), I will open the separate
implementation PR with the code, deployment package, tests, documentation, and
redacted live proof.

[roy2392]

The RFC-only draft PR is now open: #440

It includes the proposed Azure reference-architecture PNG and its reproducible msftse/azure-architecture-proposal prompt. The implementation remains separate pending RFC acceptance; the live proof boundary and the required adversarial lease follow-up are explicit in the PR.