Make the lab templates configuration instead of hardcoded Nimbus objects

[henleda]

Small, standalone, and independent of L1/L2. Nothing is removed — the cloning mechanism stays exactly as it was; only where two object names come from changes.

What create_lab does, and why cloning is right

It builds a test LB by cloning a known-good origin pool and HTTP LB, then stripping the copy back to a clean slate with every security control off. Composing a spec from scratch would discover a missing required XC field at PUT time; copying one that already works cannot. That is deliberate and unchanged.

What was wrong with the defaults

pool_template: str = "nimbus-bigip-pool", lb_template: str = "nimbus-www",

Three costs:

1. Not portable. lab-create only worked on a tenant that happened to contain objects by those names. Anywhere else it failed at the first get_origin_pool with a bare 404.
2. Not reachable. The CLI exposed only --domain, --origin, --name, --origin-tls. No flag reached either template parameter, so from the command line they were effectively hardcoded.
3. nimbus-www was doing two jobs. It was simultaneously the default source template here and the default protected object in engine.protected_lbs() — the one load balancer the tool refuses to mutate was the one it read to build every lab. Safe, because templates are only ever read and the deep copy is what gets created, but it reads oddly in a codebase this careful about blast radius.

The change

--pool-template / --lb-template, or $VPCOPILOT_LAB_POOL_TEMPLATE / $VPCOPILOT_LAB_LB_TEMPLATE — the same shape protected_lbs() already uses for VPCOPILOT_PROTECTED_LBS. Explicit argument beats environment beats default.

A missing template now names both remedies and says why a template is needed at all:

no origin pool 'not-here' in this namespace to clone as the lab template (…). lab-create builds a lab by copying a known-good origin pool so every required XC field is present. Point it at one of yours with --pool-template, or set $VPCOPILOT_LAB_POOL_TEMPLATE.

That is the first failure any other tenant hits, so it should say what to set.

No regressions

The defaults keep the same values, so behaviour on this tenant is identical — pinned by test_the_defaults_are_unchanged_so_this_tenant_behaves_identically, which asserts the two template reads are still nimbus-bigip-pool and nimbus-www when nothing is configured.

Also pinned: environment override, explicit-argument precedence, an empty env value falling back rather than asking XC for an object named "", the error naming both remedies, that the CLI actually reaches both parameters, and — the one worth keeping — that the templates are only ever read, never written, since that is what makes it safe for the default template to also be the protected object.

Verification

785 tests pass with XC_API_URL/XC_API_TOKEN/XC_NAMESPACE unset and no .env, ruff clean. docs/TRY_IT.md documents both flags and the read-only property.

Context: this came out of the L1/L2 rescope (#19), which flagged it as the cheapest decoupling win in the repo — it needs no hardware decision and is worth doing whether or not L1/L2 ever start.

🤖 Generated with Claude Code