Venue config copy

The Copy feature snapshots a venue’s configuration and replays it into another venue — in the same RUCKUS One tenant or a different one. A copy is never executed directly: it compiles into a MOP that you review, run under arming, and can reverse.

Enable it under Features in the dashboard. It is generally available — no password.

The pipeline

Six steps, two of them gates:

venue_extract produces the snapshot. venue_copy_plan diffs that snapshot against the target venue and compiles the apply-MOP — it writes nothing. You review the compiled steps with mop_replay { dryRun: true }, then run it with armWrites: true, which names the target tenant before any write executes. venue_copy_verify re-diffs afterwards to report what did not land, and venue_copy_undo compiles a delete-MOP that reverses the run.

The copy engine is built on the MOP machinery rather than beside it. There is no separate copy runner, so a copy is reviewable, resumable, and auditable exactly like any other MOP. Enabling copy gives you the mop_* tools even if you don’t have Live CLI enabled.

Step 1 — extract a snapshot

venue_extract walks the venue’s config surface into a portable snapshot: venue metadata, WLAN activations plus the full shared WLAN definitions, switch profiles / VLANs / ACLs, AAA, AP groups and radio settings, the AP venue settings, and the switch inventory.

It is chunked for the 30-second run budget. One call walks a bounded batch of domains and returns { snapshotId, complete, domainsDone, domainsRemaining }. If complete is false, it must be called again with the same snapshotId until it is true — a plan built on an incomplete snapshot skips objects whose definitions were never captured.

A domain that errors — a feature the tenant hasn’t provisioned returns 404, or a transient 5xx — is recorded with its status and never aborts the run. Partial snapshots are useful and resumable.

The config blob itself is never returned to the conversation, because it can carry WLAN and RADIUS secrets. You get per-domain counts and a size.

Tool	What it does
venue_extract	Capture (or continue capturing) a venue into a snapshot
venue_extract_domains	List the config domains a snapshot can capture
venue_snapshot_list	Your snapshots — venue, tenant, status, counts, size
venue_snapshot_get	One snapshot’s metadata (never the config blob)
venue_snapshot_delete	Delete a snapshot

Note

Snapshots are useful on their own, before any copy is involved — a point-in-time venue configuration backup and an as-built documentation artifact.

Step 2 — plan the copy

venue_copy_plan diffs a completed snapshot against a target and compiles the apply-MOP. You give it the snapshotId and exactly one of:

• target.venueId — copy into an existing venue, or
• target.newVenue.{name, address} — create the venue as part of the copy.

The mode is chosen by targetConnection:

Mode	How you select it	What happens to shared objects
Same-tenant	Omit targetConnection, or name the snapshot’s own source connection	The WLANs and switch profiles already exist — the plan re-does the activation joins against their existing ids. Nothing shared is created.
Cross-tenant	Name a different saved connection	The shared objects don’t exist in the target tenant, so each is created there, its dependencies bound, and then activated.
Template	mode: "template"	Builds a reusable venue template on the /templates/venues surface instead of a real venue. Requires target.newVenue.

Per object, the diff resolves to create, skip-identical, or collision. collisionPolicy decides the last one: skip (the default) leaves a differing object as it is; update overwrites it.

The plan returns { mopId, mode, crossTenant, perDomain, stepsByDomain, totalWrites, warnings, operatorInputRequired, next }. Read the warnings before running — they name the cases the copy could not resolve on its own.

See What a venue copy carries for the per-domain support matrix, and call venue_copy_support for the authoritative version derived from the planner’s own write registry.

Write-only secrets

Some secrets are write-only: the source API accepts them on create but masks them on read. A copy can only carry such a value verbatim when the source tenant returns it in the clear.

• Readable at the source — the value copies through verbatim. Nothing to do.
• Masked at the source — the field becomes a {{binding}} placeholder and is listed in the plan’s operatorInputRequired manifest as {domain, name, field, hint, binding}. The run refuses with missing_capture until you supply the value in a bindings map at run start.

The affected fields are RADIUS shared secrets (AAA servers and 802.1X RADIUS server profiles), AAA bind passwords, the guest-portal external key and social-login OAuth app secrets, and DPSK passphrases.

A masked secret is never silently dropped and never invented. A plan against a tenant that masks secrets is not a failure — it is telling you exactly which values to hand it.

The two safety gates

Live-target guard (plan time). Copying into an existing venue that already has onboarded devices or activated config refuses with error: "target_not_empty", reporting the target’s AP, switch, activated-WLAN, and switch-profile counts. Pass acceptWarnings: true to proceed. A brand-new target.newVenue is always empty and is never gated — the server cannot know which venue is production, so populating one has to be a conscious decision.

Run arming (run time). The generated MOP declares one connection target that every write step runs against, so mop_replay / start_auto require armWrites: true, and arming names the exact tenant before any write executes.

These are separate boundaries and both apply.

Caution

Never copy into a live production venue without an explicit per-operation OK. Cross-tenant end-to-end runs belong on test tenants.

Step 3 — verify

venue_copy_verify re-diffs the snapshot against the now-populated target venue and reports residual deltas — what would still be created or updated. Run it after applying a plan to confirm the copy landed. Pass the same snapshotId, targetVenueId, and collisionPolicy you planned with.

It returns { complete, residualWrites, perDomain, warnings } and is read-only: it issues GETs only.

Step 4 — undo, if you need it

venue_copy_undo compiles a delete-MOP that reverses a completed copy. Pass the runId of the copy run (mop_replay / start_auto report it).

The undo is driven by exactly what the copy captured: the venue it created — deleting which cascades its settings, AAA servers, AP groups, and WLAN activations — plus any shared objects a cross-tenant copy created in the target tenant. Deletes run in reverse dependency order: venue first, then WLANs, ethernet-port profiles, RADIUS server profiles, DPSK pools, portal profiles, and identity groups.

Like every other step it compiles but does not run. Review with mop_replay { mopId, dryRun: true }, then run it armed.

Its limits are worth knowing before you rely on it:

• A same-tenant clone joins existing shared objects and creates nothing new, so there is nothing to undo — only a newly created venue is deletable.
• A copy into an existing venue does not delete that venue, and the venue-scoped objects it created there are not captured with reversible ids, so only the shared objects it created are undone. You are warned when this applies.
• Only a run that was armed can be undone.

Danger

An undo issues real DELETEs against the target tenant. Review the compiled steps before arming it.

Limits

Limit	Value
Snapshots per user	20 — delete one with venue_snapshot_delete if full
Snapshot retention	30 days
Oversized extraction	Returns snapshot_too_large — restrict domains and re-extract

venue_extract and venue_copy_verify never write to R1. The only writes happen when you run a venue_copy_plan MOP, armed.

Next steps

• What a venue copy carries — the per-domain matrix
• Live CLI and MOPs — the engine that runs a copy plan
• Multiple connections — how a cross-tenant target is named
• Write Guard — confirm-before-write on top of arming