dav: import the DCM validation corpus - #65
Conversation
fa4df1a to
eda2d70
Compare
Adds the DAV validation corpus (dav/) -- the use-case set DCM is validated against -- so the spec ships with its conformance dogfood. Single-concern; independent of the UDLM/DCM split. Signed-off-by: Chris Roadfeldt <chris@roadfeldt.com>
eda2d70 to
93af608
Compare
| @@ -0,0 +1,180 @@ | |||
| { | |||
| "$schema": "http://json-schema.org/draft-07/schema#", | |||
There was a problem hiding this comment.
please provide some description which properties are used for what
There was a problem hiding this comment.
Done — every property now carries a description (its purpose, its form, and whether it's authored or server-owned), plus a schema-level description of what a UC is.
| uuid: uc-seed-001a | ||
| handle: compute/vm-standard-provision | ||
| scenario: | ||
| description: An application team requests a new virtual machine with standard multi-tenant |
There was a problem hiding this comment.
I think this use case covers too much. I think that tenancy should be handled in another use case
There was a problem hiding this comment.
Agreed it was covering too much. I split it: this UC is now scoped to standard VM provisioning only, and the data-plane tenant-isolation concern moved to its own UC (compute/vm-tenant-isolation-enforcement), with the tenancy data model in compute/tenancy-data-model.
| uuid: uc-seed-bfi-001 | ||
| handle: cross-domain/ansible-inventory-brownfield-ingestion | ||
| scenario: | ||
| description: An operations team manages an existing estate (bare metal, VMs, |
There was a problem hiding this comment.
nice discovery use case. What I am missing is how the use should manage the infra once it is discovered. Should we continue to allow the user to manage in the old way and keep the data in sync or should we ask the user to use dcm api?
There was a problem hiding this comment.
Good question — it deserved its own UC rather than an inline answer. I added a companion adoption UC (cross-domain/brownfield-adoption-capability): adopt-in-place, a coexistence window that tracks out-of-band changes as drift, then a cutover that flips authority to the DCM API. Whether continued out-of-band management is allowed after cutover is a policy-configurable action (default reject+alert), so it's an explicit choice rather than left to the reader.
| uuid: uc-seed-002a | ||
| handle: cross-domain/sovereign-decommission-with-peer | ||
| scenario: | ||
| description: A sovereign-profile tenant initiates decommissioning of a resource |
There was a problem hiding this comment.
this use case seems to be related to rehydrate flow. Why it is important whether it is done from sovereign env or not?
There was a problem hiding this comment.
The sovereign/peer angle is the point, not rehydrate. This UC is a peer-coordinated decommission — a two-phase release across both DCM instances with a single, consistent cross-DCM audit trail — which is distinct from rehydrate (rehydrate replays Intent into a new Requested state on another provider; this releases both existing replicas). I clarified that in the scenario so the distinction is explicit.
| uuid: uc-seed-008a | ||
| handle: cross-domain/tenant-onboarding | ||
| scenario: | ||
| description: A platform engineer onboards a new tenant into the FSI-profile DCM |
There was a problem hiding this comment.
please clarify the relationship between tenant and profile? Should the relationship between the two be determined by policies? Why do we need to have additional mapping?
There was a problem hiding this comment.
The binding is a property of the tenant boundary, not a separate mapping table: onboarding binds the tenant to the instance's resolved profile (near-term the instance applies one profile deployment-wide). The compliance/sovereignty overlay (Sovereignty Zone + Accreditation) is a separate axis from the profile. I made both explicit in the scenario.
| uuid: uc-seed-007a | ||
| handle: governance/audit-merkle-tree-verification | ||
| scenario: | ||
| description: A compliance auditor requests cryptographic verification that a specific |
There was a problem hiding this comment.
this imply we provide a way to verify consistency of historical data. We need to investigate how to do it.
There was a problem hiding this comment.
Right — that's the requirement this UC asserts, not a committed mechanism yet, so "we need to investigate how" is the correct read: the UC is what puts that investigation on the board. The concrete hash-chain structure belongs in the audit-store design; happy to cross-link the two so the requirement and the design track together.
| uuid: uc-seed-009a | ||
| handle: governance/minimal-profile-policy-scope-boundary | ||
| scenario: | ||
| description: A developer in a minimal-profile personal sandbox tenant provisions |
There was a problem hiding this comment.
is this related to how policies are implemented and enforces?
There was a problem hiding this comment.
Yes — it validates policy-scope behavior. Under the minimal profile the FSI-scoped policies (data-residency, dual-approval, encryption-at-rest) aren't part of the request's resolved profile, so they must not evaluate; the request proceeds under only what the minimal profile carries. It checks that a minimal profile enforces its floor and nothing above it.
| uuid: uc-seed-003a | ||
| handle: identity/auth-provider-drift-detection | ||
| scenario: | ||
| description: The DCM control plane detects that the identity provider's view of |
There was a problem hiding this comment.
why dcm needs to cache user/group membership? shouldn't we delegate it to identity provider?
There was a problem hiding this comment.
DCM does delegate to the IdP and doesn't keep an authoritative membership cache. The only exception is a disconnected/sovereign deployment, where it may hold a point-in-time identity projection (provenance=observed) to keep operating while the IdP is unreachable. This UC is about detecting when that projection has diverged from the IdP once connectivity returns — the IdP stays authoritative.
| uuid: uc-seed-obs-001 | ||
| handle: observability/udlm-universal-telemetry-export | ||
| scenario: | ||
| description: A platform operations team connects its existing observability |
There was a problem hiding this comment.
I would like to understand a bit more about this use case. I am not sure how we can achieve this without writing adapters.
There was a problem hiding this comment.
No per-tool adapters: DCM exposes one UDLM-modeled, schema-discoverable export surface over standard transports — OTLP, Prometheus scrape, and a message-bus subscription against the published event catalog. Any tool that speaks a standard transport consumes it, so "no adapters" means no DCM-side per-tool integration code — that's the requirement this UC tests.
Brings this PR's files up to the current DCM spec state (post UDLM/DCM separation, AEP alignment, taxonomy reconciliation, and review resolutions). Content-only update on existing paths. Signed-off-by: croadfeldt <chris@roadfeldt.com>
e3a0a7b to
3707b45
Compare
…e/identity/infrastructure/observability use-cases) Adds the remainder of the DCM validation use-case corpus developed upstream — tenancy, brownfield adoption, composite services, audit-chain, policy resolution, identity/delegation, bootstrap, rehydration, drift/telemetry. Depends on #65 (initial corpus import); kept as a separate additive slice so Signed-off-by: croadfeldt <chris@roadfeldt.com> #65's in-flight review threads are undisturbed.
|
Thanks @pkliczewski — captured, not closed. Superseded by the ordered, scoped set (#109–#117), tracked in #108; your feedback carries forward as CF-10 (brownfield discovery lifecycle — answered by the estate-observation flow). See #108. |
2 participants
Decision: Add the DAV validation corpus (
dav/) — the use-case set DCM is validated against — so the spec ships with its conformance dogfood.Part of the staged upstreaming: single-concern ≤3k. This PR:
dav/only (+1,151). Independent of the split; pairs with the architecture PRs each use case exercises.Draft — sample for review pending team re-engagement.