Installation Manual - 116 hub-dr-v7 deployment program plan

The milestone, workstream, phases, validation matrix, and reproducibility plan for the hub-dr-v7 warm standby deployment.

This chapter records the deployment program for hub-dr-v7, before live deployment work begins.

The goal is a fully validated, documented, reproducible warm standby management cluster for hub-dc-v7.

Governance

Certification Boundary

In this workstream, certified means internally certified for the CompTech lab:

• every phase has evidence;
• every live change has an issue and rollback path;
• every important state is reproducible from recorded inputs;
• OpenShift health, GitOps health, operator health, backup readiness, compliance scans, security checks, and failover readiness are validated;
• documentation exists locally and in this public installation manual.

This is not an external Red Hat certification, PCI DSS ROC/AOC, QSA, ISO, or bank-auditor attestation. External attestation requires a separate auditor-led track.

Non-negotiable Controls

• hub-dr-v7 stays warm standby until a failover issue explicitly promotes it.
• Do not clone hub-dc-v7 identity: no copied etcd, cluster ID, kubeconfigs, OAuth secrets, service-account signers, RHACS runtime secrets, or ACM runtime state.
• No live mutation without a phase issue, milestone, ADR coverage, validation plan, rollback path, and closeout.
• Do not print or commit secrets, kubeconfigs, pull secrets, PATs, Vault tokens, private keys, passwords, or full Secret manifests.
• Durable OpenShift state must be GitOps-first.
• Every material cluster gate must update this installation manual before closeout.

Target State

Phase Line

The issue line remains granular for auditability. Execution and public documentation from #451 onward should be batched so each article reads as a complete runbook.

Batch Execution Model

The remaining work is grouped into four execution batches. Each batch may close multiple child issues, but the public installation manual should get one comprehensive article per batch.

Future articles should include objective, non-goals, entry criteria, execution sequence, rollback, validation matrix, secrets handling, GitOps/live deltas, residual risks, and the next-batch decision.

Gate Model

Every phase must close with:

• issue comment with what changed;
• validation evidence;
• files touched;
• live systems touched;
• rollback or promotion decision;
• residual risks;
• next gate;
• local session record;
• updated local memory files;
• blog chapter or blog update when the gate is material.

Validation Matrix

Final Done Criteria

hub-dr-v7 is complete only when all are true:

1. cluster is installed and healthy;
2. platform GitOps is synced and healthy;
3. management services are installed in standby-safe mode;
4. backup, restore readiness, and secret custody are proven;
5. compliance and hardening evidence is closed or explicitly excepted;
6. operational readiness checks pass;
7. failover runbook dry-run is complete;
8. controlled takeover drill is completed or explicitly deferred;
9. public installation manual and local runbooks are complete;
10. reproducibility evidence pack is complete.

Next Gate

The next execution unit is Batch 1:

#451 / OP-GF-HUBDRV7-5: render hub-dr-v7 agent ISO and create VMs
#452 / OP-GF-HUBDRV7-6: validate base hub-dr-v7 OpenShift install

The closeout should be one comprehensive build and base-install article, not two thin gate notes.