User Provisioning → OCP Sandbox API
Approach B: OCP Sandbox API
Declare namespaces in __meta__.sandboxes; Sandbox API creates them, applies quotas, and optionally creates an RHSSO user. Simpler than Scheduler-Only — no cluster provisioner, no Keycloak role, no Gitea role.
The AgV common.yaml (OCP Sandbox API)
# ============================================================
# AgnosticV common.yaml — Simple Lab Example
# Pattern: OCP Sandbox API
# ============================================================
__meta__:
deployer:
type: agnosticd
# Sandbox API creates each namespace listed here.
# All entries with the same alias land on the same cluster
# (use cluster_condition: same('alias') for multiple namespaces).
sandboxes:
- kind: OcpSandbox
alias: sandbox # logical name for this sandbox
namespace_suffix: user # created namespace: sandbox-{guid}-user
cloud_selector:
cloud: aws-us-east-1
purpose: prod
quota:
cpu: "8"
memory: "16Gi"
pods: "30"
# Optional: create RHSSO user (only on clusters with Keycloak)
keycloak: "yes"
# Second namespace on the SAME cluster (note cluster_condition)
- kind: OcpSandbox
alias: sandbox
namespace_suffix: tools # created namespace: sandbox-{guid}-tools
cluster_condition: "same('alias')" # MUST use same cluster as above
quota:
cpu: "4"
memory: "8Gi"
pods: "20"
# Variables injected by Sandbox API (use directly in roles):
# sandbox_openshift_api_url — cluster API URL
# sandbox_openshift_ingress_domain — apps domain for building routes
# sandbox_openshift_console_url — web console URL
# sandbox_openshift_namespace — primary namespace (sandbox-{guid}-user)
# cluster_admin_agnosticd_sa_token — cluster-admin token
# sandbox_username / sandbox_password — RHSSO user (if keycloak: yes)
# ── Workload roles ─────────────────────────────────────────────
agnosticd_roles:
# Deploy lab application into the sandbox namespace
# (namespace already created by Sandbox API)
- role: ocp4_workload_my_lab_app
vars:
app_namespace: "{{ sandbox_openshift_namespace }}"
app_image: registry.access.redhat.com/ubi9/ubi-minimal:latest
# Deploy Showroom with Sandbox API injected variables
- role: ocp4_workload_showroom
vars:
showroom_namespace: "{{ sandbox_openshift_namespace }}"
showroom_git_repo: "https://github.com/rhpds/showroom-my-lab"
showroom_extra_vars:
console_url: "{{ sandbox_openshift_console_url }}"
username: "{{ sandbox_username }}"
password: "{{ sandbox_password }}"
What Sandbox API does vs what you do
| Task | Sandbox API (OCP pattern) | Your roles |
|---|---|---|
| Select cluster | Yes — based on cloud_selector | — |
| Create namespaces | Yes — from namespace_suffix entries | — |
| Apply ResourceQuota | Yes — from quota: in each sandbox entry | — |
| Create OCP local user | Yes — automatically | — |
| Create RHSSO user | Yes — if keycloak: "yes" | — |
| Deploy lab application | — | Yes — via workload roles |
| Deploy Showroom | — | Yes — via ocp4_workload_showroom |
| Create Gitea repos | — | Yes — if needed |
| Destroy namespaces | Yes — automatically on order destroy | — |
Destroy with OCP Sandbox API
Sandbox API deletes the namespaces it created on destroy. You do not need a destroy role for namespace cleanup. However, any resources you created outside those namespaces (cluster-level resources, RHBK users, Gitea orgs) will not be cleaned up automatically — you must handle those in your destroy roles.