taxonomy: import the DCM capability taxonomy - #64
Conversation
339dffd to
d9ea9a0
Compare
| |------|-----------| | ||
| | **GateKeeper Policy** | Typed Policy. Declares `enforcement_class: compliance` (boolean deny — halts request) or `operational` (contributes `risk_score_contribution` to request risk score). Compliance-class is the default and fail-safe. See [Scoring Model](data-model/scoring-model/). | | ||
| | **Validation Policy** | Typed Policy. Declares `output_class: structural` (boolean pass/fail — halts on fail) or `advisory` (contributes completeness score + warning list without blocking). Structural is the default and fail-safe. See [Scoring Model](data-model/scoring-model/). | | ||
| | **Transformation Policy** | Typed Policy. Output: mutations[] — field additions, changes, locks. Fires on request payload. All mutations collected and applied with provenance. | |
There was a problem hiding this comment.
what about placement policy?
There was a problem hiding this comment.
Good catch — added. There's now a Placement Policy row (the 8th typed policy): declarative affinity / anti-affinity / spread / co-locate / prefer / pin over abstract Topology kinds (never provider-native ids), evaluated by the Placement Engine, consuming UDLM Topology + capacity/utilization + provider topology_capability. Full rationale in ADR-019. Pushed.
There was a problem hiding this comment.
Good catch. Placement Policy is in now as the 8th typed policy — evaluated by the Placement Engine over abstract Topology kinds (ADR-019) — and I bumped the section header to Policy Types (8) so the count matches.
|
|
||
| | Term | Definition | | ||
| |------|-----------| | ||
| | **Request Orchestrator** | The event bus. Routes lifecycle events to the Policy Engine. Contains no pipeline logic — Policies define all behavior. | |
There was a problem hiding this comment.
what do you keeping this generic and not policy engine specific? We have other components like cost management which would need to receive lifecycle events
There was a problem hiding this comment.
Agreed — made it consumer-neutral. The Request Orchestrator now routes lifecycle events to all subscribers — the Policy Engine and any other consumer (cost management, drift reconciliation, …), never coupled to one engine. Pushed.
| | Term | Definition | | ||
| |------|-----------| | ||
| | **Red Hat Developer Hub (RHDH)** | Red Hat's enterprise distribution of Backstage. Primary deployment target for DCM consumer GUI. Provides pre-built auth (RHSSO/Keycloak), RBAC plugin, Dynamic Plugins, ArgoCD/Tekton/AAP integrations, and the PatternFly design system. | | ||
| | **Dynamic Plugin** | An RHDH/Backstage plugin loaded at runtime without rebuilding the RHDH image. DCM ships all its plugins as Dynamic Plugins — new versions deploy by updating a tag. | |
There was a problem hiding this comment.
let's remove backstage from here. Dynamic plugin functionality was rejected by upstream.
There was a problem hiding this comment.
Done. Removed the Dynamic Plugin row; RHDH is now described as one (non-required) GUI target, with DCM's plugins shipped as supported static builds, and I called out that the Backstage Dynamic Plugin mechanism was rejected upstream. Pushed.
| | **Consumer Portal** | The self-service web interface for application developers, owners, and tenant admins. Wraps the Consumer API completely. Bounded by tenancy (X-DCM-Tenant context). Features: catalog browse, request submission with scheduling and dependency groups, live SSE status stream with constituent tracking, resource management, approvals, cost and quota, notifications, sessions. | | ||
| | **Admin Panel** | The platform operations console for Platform Admins, SREs, Policy Owners, Security teams, and Auditors. Wraps the Admin API. Features: platform health dashboard, tenant management, provider registration approval, accreditation, quota, scoring configuration, approval queue, tier registry editor, audit and compliance, session management. | | ||
| | **Provider Management GUI** | The management interface for provider owner teams. One common shell (overview, health, config, audit) for all 11 provider types, with type-specific extension tabs. Service Provider extends with capacity, managed entities, naturalization; credential management service with inventory, rotation, revocation, external CA config; Auth Provider with session stats and SCIM sync; etc. | | ||
| | **Unified Shell** | A single DCM web application with role-gated surfaces: Consumer Portal (all actors), Admin Panel (platform-level roles), Provider Management (provider_owner role), Flow GUI (policy_owner/sre). One login, one session. Navigation adapts to actor's highest privilege level. | |
There was a problem hiding this comment.
why do we need this one and all other UIs?
There was a problem hiding this comment.
Trimmed. The UI block is now just the Unified Shell concept (role-gated surfaces of one app) with a pointer to the GUI specs; I dropped the enumerated feature lists and GUI-001–010 from the taxonomy — right-altitude: the taxonomy names the concept, the spec carries the detail. Pushed.
| | Term | Definition | | ||
| |------|-----------| | ||
| | **GitOps Store Partitioning** | For deployments using Git as an ingress adapter (doc 51 — optional): splitting the intent repository into multiple repositories to manage scale. Three strategies: tenant-shard (hash of tenant_uuid), per-tenant (one repo per tenant), and time-based archiving (active vs cold). Git is not a required DCM infrastructure component — it is one of several ingress paths (alongside API, CLI, and message bus). | | ||
| | **Dual-Write Mode** | Migration technique where DCM writes to both source and target store simultaneously. Required before store cutover. Duration is profile-governed (P1D minimal → P60D sovereign). | |
There was a problem hiding this comment.
please provide clarification for "dual-write mode" and "burn-in period". Why do we need it?
There was a problem hiding this comment.
Clarified. Dual-Write is now framed as the standard store-cutover safety pattern (adopt-by-reference, not redefined) — the only DCM-specific part is the profile-governed duration. Burn-In Period is defined alongside it (source stays read-only for rollback and must not be decommissioned before it completes). Pushed.
| |------|-----------| | ||
| | **Liveness (/livez)** | Fast DCM health check (PT5S max, no external calls). Failure → Kubernetes restarts the pod. Unauthenticated. | | ||
| | **Readiness (/readyz)** | DCM readiness check — validates Session Store, Audit Store, Policy Engine, Message Bus, Auth Provider. Failure → removed from load balancer. Used for startup probes. | | ||
| | **HLT-001–HLT-006** | Self-health system policies. Key: HLT-001 (livez and readyz required, unauthenticated), HLT-002 (livez PT5S max, no external calls), HLT-003 (readyz fails if core dependencies unreachable), HLT-005 (Prometheus metrics required). | |
There was a problem hiding this comment.
please clarify this. I am not sure how this is connected with health/readiness of the system
There was a problem hiding this comment.
Clarified. Liveness/Readiness are now explicitly the standard Kubernetes probe convention (adopt-by-reference); the HLT-001–006 policies just bind DCM's specifics to them — livez ≤PT5S / no external calls / unauthenticated (failure → restart), readyz validates the core stores + message bus + auth provider (failure → out of the LB). So the self-health policies are the probes, with DCM values. Pushed.
| | **HLT-001–HLT-006** | Self-health system policies. Key: HLT-001 (livez and readyz required, unauthenticated), HLT-002 (livez PT5S max, no external calls), HLT-003 (readyz fails if core dependencies unreachable), HLT-005 (Prometheus metrics required). | | ||
|
|
||
|
|
||
| ### Session Revocation Terms |
There was a problem hiding this comment.
would it be better to refer to systems like keycloak for such terms? why do we need to redefine it?
There was a problem hiding this comment.
Fair — same T5 "don't re-model a solved standard" principle I just applied to versioning / RTO / probes. I'm taking session + token revocation to follow-up: adopt-by-reference for the OIDC/Keycloak parts (token introspection is already RFC 7662) and keep only the genuinely DCM-specific piece — the fast "revoked-but-not-yet-expired" registry that every component checks on each request. I'll fold that in rather than redefining the standard. Tracking it.
There was a problem hiding this comment.
Agreed on not re-modeling a solved standard. Token introspection is now adopt-by-reference (RFC 7662, POST /api/v1/auth/introspect); the only DCM-specific term left is the Session Revocation Registry — the fast check for revoked-but-not-yet-expired sessions, which introspection alone doesn't cover.
| | **ICOM-001–ICOM-009** | Internal Component Auth system policies. Key: ICOM-001 (mTLS required for all internal calls), ICOM-002 (interaction credential required in addition to mTLS), ICOM-007 (bootstrap tokens one-time-use, PT1H max), ICOM-008 (compromised certs → CRL immediately). | | ||
|
|
||
|
|
||
| ### API Versioning Terms |
There was a problem hiding this comment.
this is already solved with available best practices. Why do we need to redefine this?
https://dev.to/zuplo/api-backwards-compatibility-best-practices-5e40
There was a problem hiding this comment.
Agreed. API versioning is now adopt-by-reference — semver + RFC 8594 Sunset / Deprecation headers — keeping only the DCM-specific values; the detail moved into the api-versioning doc (see #69). I'll mirror a one-line adopt-by-reference note in this taxonomy section too so it's consistent here. Tracking it.
There was a problem hiding this comment.
Fair — no need to redefine it. The section now states up front that DCM adopts semver + RFC 8594 (Deprecation / Sunset headers) by reference and redefines neither; what's left is only the DCM-specific part — profile-governed support windows and the VER policies. The mechanics moved to the api-versioning doc under #69.
…y foundational principles (#15) * taxonomy: drop Dynamic Plugin dep; RHDH = one non-required GUI target (dcm-project/dcm #64, pkliczewski) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * taxonomy: consolidate dcm-project/dcm #64 review (pkliczewski) — apply foundational principles - Lifecycle events consumer-neutral: Request Orchestrator routes to ALL subscribers (Policy Engine + cost mgmt + drift), not one engine (principle: consumer-neutral mechanisms; #64 L68). - Add **Placement Policy** (8th typed policy) → answers "what about placement policy?" (L40), references ADR-019. - Trim the UI block to the Unified Shell concept + cross-ref the GUI specs; drop enumerated feature lists + GUI-001–010 detail (principle: right altitude — taxonomy = concept, spec = detail; #64 L183). - RTO/RPO + Dual-Write = standard DR/cutover concepts adopted by reference, keep only DCM-specific targets (don't-redefine-solved-standard gate, T5; #64 L192). - Liveness/readiness = standard k8s probe convention by reference, keep DCM-specific deps (T5; L218). Earlier commit removed the Dynamic-Plugin dependency (rejected upstream; L140). Design-ish items (#69 field docs, dual-write rationale depth) carried to the #163 re-sync. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * generalize homelab name in DISCUSSION-TOPICS (roadfeldt-observability -> a homelab observability stack) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks Piotr — these were the right calls and I've folded several into my own guidelines. Done:
The deeper "document every field of each object" / placement-design items I'm taking to the engineering re-sync. |
…rator, adopt-by-reference Folds in Piotr's review on #64: - add Placement Policy (8th typed policy; abstract Topology kinds; → ADR-019) - Request Orchestrator is consumer-neutral (routes to all subscribers, not just the Policy Engine — cost mgmt, drift, etc.) - RHDH = one non-required GUI target; Dynamic Plugin removed (mechanism rejected upstream); plugins ship as supported static builds - UI block trimmed to the Unified Shell concept + pointer to the GUI specs (right-altitude); drop enumerated GUI-001-010 feature lists - Dual-Write / RTO / RPO / Liveness / Readiness adopted by reference (standard patterns; only DCM-specific values retained) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Brings the DCM capability taxonomy (the normalized vocabulary where use-case demand meets provider supply) into the spec as one self-contained unit. Part of the staged croadfeldt/dcm -> dcm-project/dcm upstreaming in single-concern PRs. taxonomy/ only. Signed-off-by: Chris Roadfeldt <chris@roadfeldt.com> Signed-off-by: croadfeldt <chris@roadfeldt.com>
…rator, adopt-by-reference Folds in Piotr's review on #64: - add Placement Policy (8th typed policy; abstract Topology kinds; → ADR-019) - Request Orchestrator is consumer-neutral (routes to all subscribers, not just the Policy Engine — cost mgmt, drift, etc.) - RHDH = one non-required GUI target; Dynamic Plugin removed (mechanism rejected upstream); plugins ship as supported static builds - UI block trimmed to the Unified Shell concept + pointer to the GUI specs (right-altitude); drop enumerated GUI-001-010 feature lists - Dual-Write / RTO / RPO / Liveness / Readiness adopted by reference (standard patterns; only DCM-specific values retained) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: croadfeldt <chris@roadfeldt.com>
…zed) The taxonomy was reconciled upstream (#232): Service=act / Resource=thing, providers named by yield, realize=act / Realized=state, Composite>Compound. The ten separate concept files (AtomicComponent, AtomicService, BusinessData, CoreData, Purpose, Responsibility, Role, Service, Transaction, taxonomy.md) were superseded and consolidated — this brings the PR to the current DCM-Taxonomy.md, adds the README and layer-cake figure, and removes the obsolete concept files. Signed-off-by: croadfeldt <chris@roadfeldt.com>
88be96e to
13ea627
Compare
06e6d55 to
13ea627
Compare
…feedback) Addresses Piotr's dcm PR #64 review on the capability taxonomy: - Remove the RHDH/Backstage Integration Terms block entirely (RHDH/Backstage is not a DCM dependency; the GUI is realization-neutral; Backstage Dynamic Plugins were rejected upstream). PatternFly (the design system, not Backstage-coupled) is retained under a neutral "Design System" heading. Drops DCMService/DCMResource/Software Template/Scaffolder Action/Entity Provider/GUI-011–013. - Fix the "8th Policy type" collision: Placement Policy is the 8th; ITSM Action Policy renumbered to the 9th. - Merge the duplicate "ITSM Integration Terms" section into the canonical one (GUI-014 retained). Most other PR-64 points (placement policy, consumer-neutral orchestrator, dual-write/ burn-in, health probes, unified-shell UI, keycloak terms, API-compat) were already resolved upstream this cycle. NOTE: full repo-wide RHDH removal (delete dcm-rhdh-integration-spec.md + de-RHDH the consumer-gui-spec, capabilities-matrix, platform-requirements, ADR-004/016, cncf-strategy, AI-PROMPT, project-overview) is a separate interdependent sweep — not in this commit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…-dedup taxonomy: remove RHDH/Backstage terms + dedup ITSM (PR #64 feedback)
|
Thanks @pkliczewski — captured, not closed. Superseded by the ordered, scoped set (#109–#117), tracked in #108; your feedback carries forward as CF-6 (adopt keycloak/AEP/API-versioning by reference rather than redefine — explicit adoption records, T5). See #108. |
2 participants
Decision: Bring the DCM capability taxonomy (the normalized vocabulary where use-case demand meets provider supply) into the spec as one self-contained unit.
First of the staged
croadfeldt/dcm→dcm-project/dcmupstreaming: single-concern, logical-boundary PRs ≤3k lines. This PR:taxonomy/only (+418/−72, 12 files). No dependencies; independent of the UDLM/DCM split.Draft — sample for review pending team re-engagement.