Describe an environment in plain language — and Day-2 bootstrap (RHACM, operators, object store)
Instead of picking a fixed template, you can describe the environment you want in plain language and let Wally turn it into a real spec — including Day-2 setup that runs automatically after the cluster comes up.
Describe it:
On the New Environment form there's a "Describe it — Wally builds the spec" box. Type something like "An RHACM hub with S3-compatible object storage, 12h TTL" and click "Interpret with Wally." Wally reads your intent and fills in the spec: OpenShift version, network type, cloud region, TTL, and — when you've asked for them — a bootstrap section listing operators and an object store. The form then shows a summary of what will be installed as pills (e.g. the operator names, "GCS object store (S3-compatible HMAC)") so you can review before launching. You can also do this entirely from Wally with the environment_launchCustom action, which previews the cluster parameters, operator list, object-store flag, and cost before it creates anything.
What Day-2 bootstrap does:
A plain template gives you a bare cluster. A bootstrapped environment keeps going after the cluster installs and lands it in a ready-to-use state. After the OpenShift install completes, the bootstrap step runs in order:
1. Object store (optional) — provisions a Google Cloud Storage bucket plus an HMAC key pair and injects it into the cluster as a Secret with S3-compatible credentials (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY and the storage.googleapis.com endpoint). Anything in the cluster that speaks S3 can use it immediately.
2. Operators — applies OLM Subscriptions for the operators you asked for (RHACM ships from the redhat-operators catalog with its OperatorGroup created for you) and waits for each operator's CSV to reach "Succeeded."
3. Post-install resources — applies the custom resources that turn an installed operator into a running platform. For RHACM that's a MultiClusterHub, and the step waits for it to report Running (up to ~30 minutes) before declaring success.
Fail-soft by design:
The object-store step is fail-soft: if the build service account doesn't yet have storage permissions, it logs a warning and the cluster still comes up — you just won't have the injected S3 Secret. The operator and ready-gate waits have their own deadlines so a slow operator doesn't hang provisioning forever.
When to use it:
Reach for a described/bootstrapped environment when you want a working platform, not just a cluster — a hub-and-spoke RHACM demo, an environment with object storage already wired for backups or registries, or any lab where the operators and their CRs should already be installed when you open the console.