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; the services WLANs bind — DPSK pools, passphrases and identity groups, portal service profiles, RADIUS server profiles, VLAN pools, Wi-Fi calling profiles, and access-control profiles with their L2/L3 ACL, device and application policies; switch profiles / VLANs / ACLs; AP ethernet-port profiles; AAA servers; AP groups; 17 venue settings singletons (radio, mesh, LED, syslog, SNMP agent, and others); and the switch inventory. venue_extract_domains lists all 46 domains.

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 capture and an as-built documentation artifact. They are working artifacts, though: 20 per user, aged out after 30 days. To keep one, seal it as a backup, which is retained indefinitely.

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 R1 console’s own /rec/templates/venues surface instead of a real venue, so the result appears on the operator’s Templates screen. Requires target.newVenue.

target.connection and a top-level connection are accepted as aliases for targetConnection; two that name different connections are refused with ambiguous_target_connection. Unknown keys are rejected rather than silently ignored — there is no dryRun on venue_copy_plan, because the plan never writes; review it with mop_replay { dryRun: true }.

Per object, the diff resolves to create, skip-identical, or collision. Which collision policy applies depends on what kind of object it is — see below.

The plan returns { mopId, target, mode, crossTenant, collisionPolicy, venueCreate, perDomain, stepsByDomain, totalWrites, stepCount, warnings, operatorInputRequired, next }. Read the warnings before running — they name the cases the copy could not resolve on its own. If the target already matches the snapshot, it returns “Nothing to copy … No MOP was created” with no mopId.

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.

When the name already exists in the target

Copying into a tenant you have copied into before is the normal case, not the exception, and two different settings govern it. They are not interchangeable.

Setting	Applies to	Values
collisionPolicy	Venue-scoped objects — AAA servers, AP groups, the settings singletons	skip (default) leaves a differing object alone; update overwrites it
sharedCollision	Tenant-scoped shared objects — WLANs, switch profiles, ethernet-port profiles, portals, RADIUS profiles, DPSK pools, identity groups, VLAN pools, Wi-Fi calling profiles, and the access-control family	adopt (default), overwrite, or skip

Objects that are already identical are skipped under either setting.

adopt is the default, and it is the behavior to understand. The existing target object is reused as it is: everything that referred to the copied object is wired to its id instead, and if it is the kind of object a venue activates, it is activated on the new venue. The object itself is never modified, and none of this copy’s profiles are bound to it.

overwrite rewrites the existing object from the source and binds this copy’s profiles to it.

skip leaves it alone and doesn’t wire or activate it, so the copy lands without that object.

In template mode the target tenant is not searched for existing template objects, so adopt never finds one: a template copy creates its shared objects afresh.

Caution

Matching is by name only — contents are never compared. An adopt can join your copy to an object that merely shares a name, and an overwrite can stomp one. An overwritten shared object may be in use by other venues in that tenant, which will see the new configuration.

Every adopted or overwritten object is named in the plan’s warnings. Read them.

Note

Nothing adopted or overwritten is ever deleted by venue_copy_undo, and an overwrite cannot be reversed — the previous body is not retained. The undo is safe by construction rather than by flag: it can only delete ids the copy itself created.

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 source config 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 exactly one source — the snapshotId you planned with, or a backupId — plus targetVenueId and the same collisionPolicy, so the residual counts line up.

It returns { complete, residualWrites, perDomain, warnings, verifyLimits, subCollections } and is read-only: it never writes (it issues GETs and read-only …/query POSTs).

complete does not mean “everything was checked”. Read verifyLimits for what a re-diff structurally cannot cover:

• Fields R1 never returns on a read — DPSK passphrases, RADIUS and AAA secrets — cannot be compared by any re-diff, in either direction.
• A sub-collection is judged from its parent, not compared item by item. The passphrases under a DPSK pool are the case that matters, so subCollections reports a per-parent source-versus-target row count as the strongest evidence available. A count mismatch is ambiguous — either the children were never created, or the parent was adopted and keeps its own — so it is reported and deliberately never folded into complete.

Verifying a template copy

A template copy has no venue to re-extract, so pass mode: "template" and targetTemplateId instead of targetVenueId. Settings domains are re-read and compared field by field; everything else is checked by exact name. It returns { complete, checked, missing, differing, unverified, checks, verifyLimits, plannedSkips, warnings, next } plus the template’s id and name.

Template verify is the confirmation that a template copy landed — the run’s own steps are not. On the console template surface R1’s activity status is unreliable in both directions, so a template write whose activity never resolves is passed with a note rather than failed; only a terminal failure fails the step.

• kind: "bind" checks confirm that a WLAN’s DPSK pool, VLAN pool, Wi-Fi calling, access-control or RADIUS profile is actually joined to the WLAN template, read from the profile’s own /query row. A missing bind means re-issue that one bind, not re-run the copy.
• checkFailed: true means the read failed; nothingCompared: true means the read succeeded but the template answered with none of the fields the copy wrote. Both count in unverified and neither is a match or a miss.
• plannedSkips lists objects the plan deliberately did not write, with the reason. They are not reported as missing.

complete requires zero missing, zero differing and zero unverified.

Caution

Read scope on each check. scope: "tenant" means the name exists somewhere among the tenant’s templates — it does not prove that object is attached to this venue template.

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: the venue first, then WLANs, switch profiles, ethernet-port profiles, RADIUS server profiles, DPSK pools (their passphrases first), any identity groups R1 auto-generated from those passphrases, portal profiles, VLAN pools, Wi-Fi calling profiles, access-control profiles, their child L2/L3 ACL, device and application policies, and finally identity groups. For a copy into an existing venue, each created WLAN is deactivated and each switch profile disassociated on the venue before it is deleted.

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.
• The run’s record is kept for 7 days after it started. After that venue_copy_undo returns run_not_found and anything the copy created has to be removed by hand.

Danger

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

Limits

Limit	Value
Snapshots per user	20 — shared with element snapshots and the working snapshots backup_create leaves; at the cap venue_extract returns snapshot_limit_reached, so delete one with venue_snapshot_delete
Snapshot retention	30 days
Snapshot size	5 MB of captured config; over it returns snapshot_too_large — restrict domains and re-extract
Compiled copy MOPs	100 per user, kept 30 days — see the caution below
Undo window	7 days from the run’s start — the run record is then swept and venue_copy_undo returns run_not_found

Snapshot config blobs are encrypted at rest, because they can carry DPSK passphrases and RADIUS secrets, and no tool ever returns one.

Caution

The MOPs the copy engine compiles are capped differently from the ones you author. At 100, the oldest is evicted rather than the new one refused — the alternative would be a copy workflow that blocks on rows you never asked to keep. If a compiled plan is one you need to retain, mop_export it. A compiled MOP that still has a run is never evicted or aged out while that run exists — undo needs it — so the count can sit above 100 until the run expires.

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: what carries same-tenant, cross-tenant, and into a template.

Copying one object Copy a single WLAN or profile with its dependency closure, without a venue.

Venue backups Keep a venue's configuration indefinitely, encrypted, and restore it later.

Live CLI and MOPs The engine that reviews, arms, and runs a compiled copy plan.

Multiple connections How a cross-tenant target is named and kept isolated.

Write Guard Confirm-before-write, on top of run arming.