Workload onboarding
Java/JBoss application path on OpenShift
This page tracks only the OpenShift side of application onboarding: namespace ownership, image deployment, runtime configuration, health checks, service mesh opt-in, and GitOps promotion to the spokes.
Architecture
Target OpenShift shape
| Layer | OpenShift object | Notes |
|---|---|---|
| Namespace | Project / Namespace | Owned by the workload repo and placed only on the intended spoke cluster. |
| Runtime | Deployment | Java/JBoss image with requests, limits, probes, and rollout strategy. |
| Configuration | ConfigMap plus Secret references | Non-secret runtime settings in Git; sensitive values supplied through ESO from external Vault. |
| Traffic | Service, Route, or mesh gateway objects | Choose Route for simple ingress or mesh gateway resources when OSSM 3 routing is required. |
| Policy | NetworkPolicy, placement, and backup labels | Restrict namespace traffic only after required ingress, egress, and platform paths are known. |
GitOps
Repository boundary
- Application manifests belong in the workload repository, not the platform repository.
- Platform-owned shared controls such as operators, mesh control plane, backup platform, and ESO remain in the platform GitOps repository.
- App overlays should target
spoke-dcfirst unless an explicit DR placement decision is made. - Keep secret values, pull secrets, and full Secret manifests out of Git.
Checklist
Before first deployment
- Create namespace: include ownership labels, backup labels, and monitoring labels as required.
- Add workload manifests: Deployment, Service, Route or Gateway, ConfigMap, probes, resource requests, and service account.
- Wire secrets: create app-specific Vault policy, Vault role, and ExternalSecret references using the validated ESO pattern.
- Choose mesh mode: opt the namespace into OSSM 3 ambient mode only when workload routing and telemetry expectations are clear.
- Define DR posture: decide whether
spoke-dris restore target, passive standby, or active-passive mirror for the app.
Out of scope
Non-OpenShift dependencies
Application-specific external services are not tracked in this OpenShift wiki unless they are required to explain OpenShift placement, secret delivery, routing, monitoring, backup behavior, or recovery. Keep this section limited to OpenShift-facing requirements and links.