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

TaskSandbox API (OCP pattern)Your roles
Select clusterYes — based on cloud_selector
Create namespacesYes — from namespace_suffix entries
Apply ResourceQuotaYes — from quota: in each sandbox entry
Create OCP local userYes — automatically
Create RHSSO userYes — if keycloak: "yes"
Deploy lab applicationYes — via workload roles
Deploy ShowroomYes — via ocp4_workload_showroom
Create Gitea reposYes — if needed
Destroy namespacesYes — 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.

← Previous: Overview + Scheduler-Only Next: Namespace Quotas + Variables →