Overview of the CompTech Platform

What the CompTech platform is, the audience for this documentation, the shape of the v6 fleet (hub-dc-v6 + spoke-dc-v6), and how this docs site relates to the source-of-truth in opp-full-plat.

This is the front door for the CompTech Platform documentation. If you’ve just arrived, this page tells you what the platform is, who this site is written for, the shape of the fleet you’ll be reading about, and how this published site relates to the private operator workspace where the source-of-truth actually lives.

What the CompTech platform is

The CompTech platform is a BFSI-oriented operating environment built around two active OpenShift clusters and a fleet of supporting platform VMs. It is being rebuilt from the ground up under the “v6” naming generation, intentionally as a disconnected / internet-unreliable environment — everything from operator catalogs to application base images is mirrored locally, no workload may rely on an upstream registry at runtime, and admission is being prepared to enforce that allowlist after the mirror inventory stabilizes.

Three operating principles drive almost every concrete decision documented in the rest of this site:

1. GitOps is the only normal change channel. Every resource reconciled by an Argo CD Application or ApplicationSet is changed only by a merged commit. oc edit, console mutation, and direct API calls are break-glass exceptions with mandatory record-keeping. ADR 0025 codifies this; the “Operations” section walks through the runbook.
2. Ownership boundaries are physical, not aspirational. The OpenShift platform GitOps repository is OpenShift-operations-only; application teams literally cannot write to it. VM-hosted platform tools live in their own repository tree. Divisions get their own application and application-GitOps repositories. ADR 0015 records the federated GitOps layout; ADR 0024 nails down the OpenShift-only boundary.
3. Images come from local Nexus, period. OpenShift platform mirror, developer base-image pulls, and CI-produced application image pushes each have their own dedicated registry hostname backed by a separate Nexus repository. ADR 0019 records the Nexus-only image supply chain; the Lab Infrastructure section walks through the three endpoints.

The lab serves as the disconnected reference build for the broader CompTech program. It is small — two OpenShift clusters, roughly a dozen supporting VMs — but the patterns it exercises (federated GitOps, ACM pull model, Vault + ESO bridging, PCI-DSS Compliance Operator baselines, image-supply guardrails) are explicitly designed to scale to additional clusters and divisions without redesigning the operating model.

Audience

This site is written for four overlapping audiences:

If you are operating the platform — making changes, troubleshooting, onboarding a new tenant — the source-of-truth runbooks live in the private opp-full-plat workspace, not here. This site is published with sanitized prose; internal IP addresses, credentials, and secret values are redacted. Treat this site as the orientation layer.

Fleet shape

The diagram above is the full v6 fleet at a glance. Read it as four bands:

1. Top band — the two OpenShift clusters. hub-dc-v6 is a compact three-node management cluster running RHACM, OpenShift GitOps, and the gitops-addon that wires hub Argo into ACM placement. spoke-dc-v6 is a six-node workload cluster (three control-plane VMs plus three physical workers gold-1, gold-2, gpu-01) running ODF, ESO, the ACS Sensor, OADP, LokiStack, TempoStack, and tenant application workloads.
2. Middle band — operator subsystems. Each labelled block is an OpenShift operator and its operand stack. Most live on the spoke; only ACM/MCE and the hub Argo instance live on the hub. The exact installed-versions list is in Lab Infrastructure §Operator Inventory.
3. Lower-middle band — platform VMs. HAProxy provides the public/private edge with TLS termination; PowerDNS holds the authoritative sub.comptech-lab.com zone and serves the lab recursor; GitLab CE is the operational Git source; Vault holds per-app secrets under the secret/apps/<division>/<app>/... convention; Nexus exposes three Docker endpoints (install, dev pull, app push).
4. Bottom band — supporting VMs and the planning anchor. MinIO holds evidence and backup data, Jenkins runs CI, SigNoz captures application telemetry, the Docker runtime VM serves non-OpenShift app workloads, and the oc-mirror worker VM runs oc mirror --v2 to refresh OpenShift platform content into Nexus. GitHub zeshaq/opp-full-plat is the planning anchor — issues, milestones, ADRs, reports — but is never a live GitOps source.

Key relationships highlighted on the diagram:

• Green dashed arrows = pull-mode. The spoke klusterlet pulls from the hub; both Argo instances pull from internal GitLab. The hub does not push routine spoke configuration; it coordinates placement and lets the spoke reconcile its own local state. This is the ACM + OpenShift GitOps Basic pull pattern from ADR 0018.
• Purple solid arrows = data plane. Workloads pulling images from Nexus, ESO authenticating into Vault, LokiStack/TempoStack writing chunks to MinIO, OADP writing Velero backups to MinIO.
• Black solid arrows = control / request. Jenkins driving build pipelines; the operator subsystem relationships on the spoke.
• Red dashed arrow = explicitly NOT a path. HAProxy is for platform VM edge exposure only. OpenShift routes do not go through HAProxy; the cluster ingress operator answers *.apps.<cluster>.sub.comptech-lab.com directly.

The fleet is intentionally narrow. There is no hub-dr-v6 or spoke-dr-v6 today; those names are reserved (ADR 0022) for a future DR build that has not been authorized. The pre-v6 hub-dc / spoke-dc / hub-dr / spoke-dr clusters are decommissioned; they may appear in historical session logs but do not exist as live targets and must not appear in new manifests.

Reading order

This docs site is structured so you can read sections sequentially, jump in mid-stack, or use it as a reference manual. The suggested first-pass reading order:

1. §1 Foundations (this section). Naming conventions, network map, credential rules, glossary. Five pages, fifteen-minute read.
2. §2 Lab Infrastructure. The VMs and their roles: PowerDNS, HAProxy, GitLab, Jenkins, Nexus, Vault, MinIO, SigNoz, Docker runtime, oc-mirror.
3. §3 OpenShift Platform. The two clusters, the operator inventory, the storage layer, image supply, RHACM, OpenShift GitOps, ESO, RHACS, OADP, observability.
4. §4 Application Delivery. The developer golden path: GitLab source, Jenkins build, Trivy scan, Nexus push, OpenShift GitOps or Docker runtime deploy.
5. §5 Operations. Day-2: image-supply drift checks, operator install workflow, compliance/PCI-DSS, break-glass procedure, the platform admin handoff.
6. §6 Architecture Decisions. The ADR record, indexed and grouped by decision area. ADRs are the durable record of why; runbooks and connection-details are the how.
7. §7 References. External documentation links, vendor reference material, the lab inventory at a glance.
8. §8 History and Replay. The rebuild timeline, what was tried and discarded, the lessons-learned record.

If you are time-boxed and only have an hour, read §1 Foundations end-to-end, then jump to the §3 OpenShift Platform overview, then the Whiteboard architecture on that page. That gives you the operating model and the fleet shape; everything else is detail.

Relationship to opp-full-plat

This published site is the public face of the platform documentation. The internal source-of-truth lives in the opp-full-plat workspace at ~/opp-full-plat/ on the operator workstation and at github.com/zeshaq/opp-full-plat for the planning record. The relationship is:

When this site says “see the operator handoff” or “see connection-details/...,” that pointer is to the private opp-full-plat workspace. The public site is intentionally not a substitute for the private operator material — it is the orientation layer that makes the private material navigable.

How this site is published

This site is built with Astro using MDX and React Flow (for the Whiteboard component) and Mermaid (for sequence and state diagrams). Source lives at github.com/zeshaq/zahid. A GitHub Actions workflow builds the site on every push to main and deploys to Cloudflare Pages at blog.comptech-lab.com.

There is no live read of cluster state into this site; everything on these pages is hand-authored prose with last_reviewed: <date> frontmatter. If a last_reviewed date is more than a few months old, treat the page as historical until a session re-validates it against the source-of-truth.

Where to go next

• New here? Read Naming Conventions, Domain and Network Map, and the Glossary, then jump to your area of interest.
• Looking for a specific subsystem? The sidebar groups every page by section. Each subsystem has both a narrative overview and a runbook page.
• Looking for why? §6 Architecture Decisions is the indexed ADR record.

References

• connection-details/platform-admin-handoff.md — operator handoff (private)
• connection-details/gitlab-operator-guide.md — GitLab handoff (private)
• adr/0001-operator-workspace.md — the local operator workspace
• adr/0015-federated-gitops-repo-architecture.md — federated GitOps repo architecture
• adr/0018-acm-openshift-gitops-pull-model-v6.md — ACM + OpenShift GitOps Basic pull model
• adr/0019-nexus-only-image-supply-chain.md — Nexus-only image supply chain
• adr/0022-v6-fleet-membership.md — active fleet membership and reserved DR names
• adr/0024-openshift-only-platform-gitops-boundary.md — repo boundary
• adr/0025-gitops-only-operations-break-glass.md — GitOps-only operations + break-glass