Platform Intent → Automation → Runtime Evidence

Summary

The RWS platform uses one operating model across domains:

• Intent is explicit and versioned (modelled data + declarative manifests).
• Git is the approval boundary for intent (review before a change can be promoted to production).
• Automation is deterministic (rendered artifacts match the intent inputs).
• Runtime is reconciled, not hand-edited (replace/reconcile prevents drift).
• Evidence proves reality (captured state is compared to intended state).

This same flow covers:

• Datacenter networking: lane-scoped rollout with Location A ACI AI-only lane and Location B EVPN/VXLAN target lane, both governed by the same intent/approval/evidence model.
• OpenShift platform: cluster and add-on reconciliation via Automation and fleet governance.
• Service connectivity: service-mesh delivered as a platform-managed capability (OSSM 3).
• Backup & restore: OpenShift backups via OADP (Velero-based) with Cohesity DataProtect policies and SmartFiles storage.

Applicable Principles

• Automation First — intent and reconciliation are automated end to end.
• Observability by Default — evidence is captured for every change.
• Reliability and Resilience — workflows enforce safe recovery paths.
• Security by Design — policy controls are embedded in delivery pipelines.

Architecture

Definitions (used consistently)

• Intent: the declared desired state that is reviewed and versioned.
• Rendered artifact: the apply-ready output produced from intent (device config, Kubernetes manifests).
• Reconciliation: continuous convergence of runtime toward the rendered artifact.
• Evidence: captured runtime state that can be compared to intent and used for drift detection.

Desired intent + observed inventory (dual model)

Git is authoritative for desired logical network intent (VLAN/VNI catalogs, IP pools, policy templates, topology patterns). netbox is authoritative for the curated inventory/source-of-truth model used by automation (assets, cabling, IP allocations), but it is not a live view of operational state. Observed runtime state is derived from evidence tooling (device telemetry, snapshots, and health) and is used for drift detection and validation; treat it as operational evidence, not a complete inventory model. Approved Git intent is synchronized into NetBox as a desired overlay; automation renders from a reconciled NetBox snapshot (inventory model + desired overlay) so there is a single model at render time.

Automation mechanics

• Intent changes land via PR with schema validation in CI (validation-only; no runtime side effects).
• Inventory updates are curated into NetBox by humans, using discovery outputs, imports, or CMDB feeds as inputs.
• After merge, a sync pipeline applies approved Git intent into NetBox as a desired overlay with conflict detection and ownership rules.
• The reconciliation job builds a render snapshot (NetBox export) by joining desired overlay with the inventory model.
• The generator renders device configs from the render snapshot and stores artifacts in Git.
• AAP precheck command profiles and parser-governed assertions validate rendered intent before deployment.
• Evidence compares Git desired → NetBox inventory model/projection → device state to detect drift and stale inventory.

Reconciled projection in practice (network)

1. Git PR updates VLAN/VNI, IP pools, policy, and topology catalogs (YAML/JSON).
2. CI validates schemas; after merge, a sync job writes desired overlay objects into NetBox.
3. NetBox records human-curated inventory (devices, ports, cabling, IP allocations).
4. Reconciliation exports a render snapshot; it fails if intent references missing assets or collides with the inventory model.
5. Generator consumes the render snapshot to produce device configs.

Delivery scope for NetBox synchronization lives in WP-02 DCIM.

End-to-end flow (at a glance)

For network changes, post-merge generates and validates artifacts; deployment requires explicit promotion in an approved change window.

Capability contracts (who writes what, where)

Implementation workflows (summary)

Location B EVPN/VXLAN lane

1. Update Git intent catalogs (VLAN/VNI, IP pools, policy, topology).
2. CI validates schemas; after merge, the sync pipeline writes the desired overlay to NetBox.
3. NetBox updates its inventory model; conflicts are flagged for resolution.
4. Reconciliation exports the render snapshot.
5. Generator renders configs and stores artifacts in Git; precheck command-profile assertions validate readiness.
6. Deploy via configure replace; capture and compare raw plus parsed CLI evidence to detect drift.

Location A ACI AI-only lane

1. Update Git intent for AI-cluster-scoped network dependencies only.
2. Validate that requested changes stay within the approved ACI AI-only scope boundary.
3. Apply ACI change workflow in approved window and store evidence bundle with explicit scope-compliance records.

Cluster + add-ons

1. Update Git policies and app-of-apps manifests.
2. ACM applies placements/policies; Argo CD reconciles add-ons and configs.
3. Evidence comes from ACM compliance and Argo sync/health status.

Service mesh

1. Update Git mesh resources for either sidecar mode (istio.io/rev) or ambient mode (istio.io/dataplane-mode=ambient).
2. Argo CD syncs and OSSM reconciles control-plane and data-plane resources.
3. Evidence comes from Argo health, mesh status, and mesh telemetry.

Reference details:

• OSSM 3.2 IstioRevisionTag resource
• OSSM 3.2 IstioRevision resource
• OSSM 3.2 ambient mode install procedure

Backup/restore

1. Update Git OADP resources (DataProtectionApplication, BackupStorageLocation, VolumeSnapshotLocation, Schedule).
2. Argo CD syncs; OADP configures Velero and credentials.
3. Cohesity DataProtect applies protection group policy (retention and optional immutability controls when configured) and records run history in Helios.
4. Evidence comes from Velero Backup/Restore objects, Cohesity run history, and restore drill results.

Note: "immutability" in this context refers to Cohesity immutability controls (for example, immutable snapshots) and depends on configuration; it should not be read as a blanket WORM or S3 Object Lock guarantee (see Cohesity DataProtect datasheet).

5. VM guest-level protection uses Cohesity agents assigned to DataProtect protection groups; see topic-openshift-backup-and-restore.

Identity + policy + mesh + network contract (canonical)

1. midPoint approves entitlements and provisions groups/roles into keycloak.
2. keycloak issues OIDC tokens; OpenShift OAuth maps group claims to Git-managed RoleBinding/ClusterRoleBinding.
3. OPA Gatekeeper enforces Git-managed constraints, including required namespace labels (tenant/network/mesh) and privileged-usage guardrails.
4. Mesh membership is explicit: sidecar mode uses istio.io/rev (optionally pointing to an IstioRevisionTag), while ambient mode uses istio.io/dataplane-mode=ambient. AuthorizationPolicy matches workload identities (service accounts/principals), not Keycloak tokens. (See: OSSM 3.2 ambient AuthorizationPolicy, and OSSM 3.2 IstioRevisionTag resource)
5. Network intent consumes the same tenant/zone labels to map namespaces to VRF/VNI and network policy in NetBox; missing mappings block the render snapshot.
6. Evidence: midPoint approvals, Keycloak audit logs, RBAC diffs, Gatekeeper violations, mesh policy status, render snapshot report.

Integration points (what depends on what)

• Service mesh depends on the network baseline: MTU and east/west reachability must match the EVPN/VXLAN posture described in topic-network-nxos-evpn-implementation.
• Backup depends on identity + egress: OADP needs controlled credentials and network reachability to the Cohesity S3 endpoint; the platform standardizes this through Git-approved configuration.
• Backup and restore design details: see topic-openshift-backup-and-restore.
• Evidence is not optional: network changes must ship with pre/post evidence; cluster changes must have reconciliation status; backup changes must have restore-test outcomes.

Decisions

• The platform treats Git as the single approval boundary for production-affecting change, across network and cluster domains.
• The datacenter fabric follows Git-authored desired intent synchronized into NetBox (while NetBox retains the curated inventory model) with deterministic generation and NX-OS full replace deployment (see topic-datacenter-3-0).
• The platform delivers service mesh as a managed capability with explicit membership and controlled upgrades (see topic-openshift-service-mesh-architecture).
• The platform delivers Kubernetes-native backup and restore through OADP (Velero-based) with Cohesity DataProtect policies and SmartFiles storage.

Open Questions

• Which RPO/RTO tiers map to backup schedules and restore-test cadence (see WP-16 Business Continuity and Disaster Recovery)?
• Cohesity S3 namespace conventions (per-cluster vs per-environment buckets) must be chosen before first production restores.