sandbox-cli:cluster-onboard

This skill should be used when the user asks to "onboard a cluster", "add a cluster to sandbox", "register a cluster", "onboard OCP cluster", "sandbox onboard", or "add a new shared cluster".

12 stars

Best use case

sandbox-cli:cluster-onboard is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

This skill should be used when the user asks to "onboard a cluster", "add a cluster to sandbox", "register a cluster", "onboard OCP cluster", "sandbox onboard", or "add a new shared cluster".

Teams using sandbox-cli:cluster-onboard should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/cluster-onboard/SKILL.md --create-dirs "https://raw.githubusercontent.com/rhpds/rhdp-skills-marketplace/main/sandbox-cli/skills/cluster-onboard/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/cluster-onboard/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How sandbox-cli:cluster-onboard Compares

Feature / Agentsandbox-cli:cluster-onboardStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

This skill should be used when the user asks to "onboard a cluster", "add a cluster to sandbox", "register a cluster", "onboard OCP cluster", "sandbox onboard", or "add a new shared cluster".

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

---
context: main
---

# Skill: cluster-onboard

**Name:** Sandbox Cluster Onboard
**Description:** Onboard a new OCP shared cluster to the RHDP Sandbox API.

---

## Purpose

Walk the user through onboarding a new OpenShift cluster to the Sandbox API. This includes verifying prerequisites, checking VPN, logging in to the target cluster, creating the onboard config, running the onboard command, and verifying the result.

## Workflow

### Step 1: Verify Prerequisites

Check that sandbox-cli is installed:

```bash
which sandbox-cli
```

If sandbox-cli is not installed, tell the user to run `/sandbox-cli:sandbox-setup` first and stop.

### Step 2: Verify Red Hat VPN Connection

**CRITICAL:** Always verify VPN connectivity before any sandbox-cli operation.

```bash
host squid.redhat.com
```

**If the DNS resolves** (returns an IP address like `10.x.x.x`), the user is on VPN. Proceed.

**If it fails** with `NXDOMAIN`, `not found`, or `connection timed out`, STOP and tell the user:

> You are NOT connected to the Red Hat VPN. The sandbox API is IP-restricted and all commands will fail with EOF errors. Please connect to the Red Hat VPN before proceeding.

Do NOT proceed until VPN is confirmed.

### Step 3: Check Authentication

```bash
sandbox-cli status
```

If not authenticated or token expired, tell the user to re-login:
```bash
sandbox-cli login --server <SERVER_URL> --token <TOKEN>
```

### Step 4: Gather Information

Ask the user for:

1. **New cluster API URL** - e.g., `https://api.cluster-xxxxx.dynamic.redhatworkshops.io:6443`
2. **Admin credentials** - `oc login` token or kubeconfig for the new cluster
3. **Cluster config** - Either:
   - An existing config file path (e.g., `cluster-config.json` or `cluster-config-cnv.json`)
   - Or the following details to create one:
     - `cloud` annotation (e.g., `cnv-dedicated-shared`, `aws-shared`)
     - `purpose` annotation (e.g., `dev`, `events`, `prod`)
     - `lab` annotation (e.g., `lb1401-sec-genai-guardrails-service`)
     - Any additional annotations (`virt`, `keycloak`, etc.)
     - `skip_quota` (true/false, default false)
     - `max_placements` (0 = unlimited)
     - Deployer admin SA token settings (ttl, refresh interval, target var)
     - Rate limiting settings (optional)

### Step 5: Login to Target Cluster

The user must be logged into the target OCP cluster as admin:

```bash
oc login --token=<ADMIN_TOKEN> --server=<CLUSTER_API_URL>
```

If certificate warning appears, the user may need to accept insecure connections.

Verify login:
```bash
oc whoami
oc cluster-info
```

### Step 6: Prepare Config File

If the user doesn't have a config file, create one. Example for CNV dedicated:

```json
{
  "annotations": {
    "cloud": "cnv-dedicated-shared",
    "purpose": "dev",
    "lab": "<lab-annotation>"
  },
  "deployer_admin_sa_token_ttl": "48h",
  "deployer_admin_sa_token_refresh_interval": "24h",
  "deployer_admin_sa_token_target_var": "cluster_admin_agnosticd_sa_token",
  "skip_quota": true
}
```

Example for general shared cluster with rate limiting:

```json
{
  "annotations": {
    "cloud": "cnv-dedicated-shared",
    "purpose": "events",
    "virt": "yes"
  },
  "deployer_admin_sa_token_ttl": "1h",
  "deployer_admin_sa_token_refresh_interval": "30m",
  "deployer_admin_sa_token_target_var": "cluster_admin_agnosticd_sa_token",
  "max_placements": 30,
  "settings": {
    "provision_rate_limit": 50,
    "provision_rate_window": "10m"
  }
}
```

### Step 7: Onboard the Cluster

Run the onboard command:

```bash
sandbox-cli cluster onboard <CLUSTER_NAME> --config <CONFIG_FILE>
```

The cluster name is optional -- if omitted, it's extracted from the API URL (e.g., `cluster-tdsqt` from `https://api.cluster-tdsqt.dynamic.redhatworkshops.io:6443`).

**What this does automatically:**
1. Connects to target OCP cluster via current kubeconfig context
2. Creates namespace `rhdp-serviceaccounts`
3. Creates service account `sandbox-api-manager`
4. Grants `cluster-admin` to the service account
5. Creates a long-lived token (~10 years)
6. Registers the cluster with the sandbox API
7. Validates cluster health

Expected output:
```
==> Checking cluster access...
  API URL: https://api.cluster-xxxxx:6443
  Ingress: apps.cluster-xxxxx.example.com
  Name:    cluster-xxxxx

==> Creating service account...
  Creating namespace 'rhdp-serviceaccounts'...
  Creating service account 'sandbox-api-manager'...
  Granting cluster-admin to 'sandbox-api-manager'...
  Creating long-lived token (~10 years)...
  Token created successfully.

==> Registering cluster with sandbox API...
  OCP shared cluster configuration created

==> Validating cluster health...

==> Cluster registered successfully.
```

### Step 8: Verify Registration

```bash
sandbox-cli cluster get <CLUSTER_NAME>
```

Check that:
- `valid` is `true`
- `annotations` match the config
- `api_url` and `ingress_domain` are correct
- `deployer_admin_sa_token_ttl` and related fields are set (if configured)

### Step 9: Test Placement Matching

Run a dry-run to confirm the cluster matches expected selectors:

```bash
sandbox-cli placement dry-run --selector 'lab=<LAB>,purpose=<PURPOSE>'
```

Or test against an AgnosticV catalog file:

```bash
sandbox-cli placement dry-run -f <path-to-common.yaml>
```

Expected output:
```
Result: MATCH
Matching clusters: 1
  - cluster-xxxxx
```

### Step 10: Verify Deployer Admin Token (if configured)

Wait ~10 seconds for the sandbox API to generate the deployer admin token, then:

```bash
sandbox-cli cluster get <CLUSTER_NAME>
```

Check `data.deployer_admin_sa_token_updated_at` is no longer `0001-01-01T00:00:00Z`.

## Important Notes

- The `--dry-run` flag can be used to preview the onboard payload without sending it
- The `--skip-validation` flag skips the post-onboard health check
- A health check warning (HTTP 401) right after onboard is normal -- the sandbox API token rotation may not have completed yet
- The service account token auto-renews via the sandbox API's token rotation goroutine
- `deployer_admin_sa_token_*` fields are REQUIRED if workloads need cluster-scoped access (e.g., creating namespaces, installing operators)

Related Skills

sandbox-cli:sandbox-setup

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "install sandbox-cli", "setup sandbox", "configure sandbox-cli", "get sandbox-cli working", "download sandbox-cli", or "I don't have sandbox-cli installed".

sandbox-cli:cluster-rotate

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "rotate a cluster", "replace a cluster", "swap clusters", "offboard old and onboard new cluster", "cluster rotation", "replace an old cluster with a new one", or "refresh cluster".

sandbox-cli:cluster-offboard

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "offboard a cluster", "remove a cluster from sandbox", "decommission a cluster", "sandbox offboard", "take a cluster offline", or "remove a shared cluster".

sandbox-cli:cluster-list

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "list clusters", "show all clusters", "list sandbox clusters", "show registered clusters", "what clusters are available", or "cluster list".

sandbox-cli:cluster-details

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "show cluster details", "get cluster info", "describe cluster", "cluster details", "inspect cluster", or "show cluster configuration".

showroom:verify-content

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "verify my workshop content", "review my lab module", "check my Showroom content", "validate my AsciiDoc module", "quality check my demo", "review my workshop for Red Hat standards", or "run a content review on my lab".

showroom:create-lab

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "create a lab module", "write a workshop module", "build a Showroom lab", "convert docs to a lab", "write a hands-on exercise", "create an AsciiDoc module", or "turn this documentation into a lab exercise".

showroom:create-demo

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "create a demo module", "write a Know/Show demo", "build a presenter demo", "create a Showroom demo", "write a facilitator guide", "build a demo script", or "create a presenter-led demo for RHDP".

showroom:blog-generate

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "turn this lab into a blog post", "write a blog post from this module", "generate a blog from my Showroom content", "convert my workshop to a blog", "write a Red Hat Developer blog post", or "create a blog post from my demo".

health:deployment-validator

12
from rhpds/rhdp-skills-marketplace

Infrastructure Health Checker — use this when you need to validate that a workload or service DEPLOYED SUCCESSFULLY (pods running, routes accessible, dependencies ready). This is NOT for student E2E lab testing. For student exercise validation (solve/validate buttons), use /ftl:rhdp-lab-validator instead. Triggers on: 'create a validation role', 'build health checks', 'add deployment validation', 'create post-deployment checks', 'validate my deployment', 'check if my workload is healthy'.

agnosticv:validator

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "validate my catalog", "check my AgnosticV config", "review common.yaml", "validate my RHDP catalog", "check for errors in my catalog", "lint my AgnosticV files", or "verify my catalog before submitting".

agnosticv:catalog-builder

12
from rhpds/rhdp-skills-marketplace

This skill should be used when the user asks to "create a catalog", "build a common.yaml", "add a new RHDP lab", "set up a new catalog item", "create an AgnosticV catalog", "build a dev.yaml", "add a catalog entry", or "create a new lab catalog for RHDP".