A device has four rooms and ten stages between DC-plan import and production traffic. This document lists the stages, the rooms they belong to, and the operation SandWork runs at every transition between them.

Audience: data center operators and architects · Applies to SandWork 6.x

Every device known to SandWork sits in exactly one stage. Stages are grouped into rooms. The stage is the precise position in the onboarding process; the room is the answer to the question operators actually care about: is this device carrying traffic right now, and is SandWork allowed to configure it?

Devices move between stages through transitions. A transition is never just a label change: each one runs real work against the device (a cable check, a traffic drain, a reconciliation) and only updates the stage if that work succeeds. In the portal the forward moves are labelled Promote and the backward moves Demote.

The rooms before Managed exist to catch two specific mismatches before a device is trusted with production traffic. Onboarding proves the physical install is correct: the box is in the right rack, cabled to the right neighbors, running the expected OS version. Staging proves the logical install is correct: the service intents recorded in SandWork are fully pushed to, and confirmed on, the device's running configuration. A device reaches Managed only once both checks have passed, and reconciliation keeps re-checking the second one for as long as the device stays in production.

Read this table first. Almost every question about staging is answered by it.

Open

Only four pieces of real work sit behind every arrow on the map. Learn these four and the whole diagram becomes readable.

Connected → Onboarded

Proves the physical install matches the plan before anything else is attempted.

• Checks the OS version and updates the image record.

• Pushes the greenfield base configuration, or bypasses it if the device was pre-staged.

• Runs a cable check against the neighbors declared in the DC plan, retrying on a configured interval.

Every move toward Staging

Drains the device so it can be worked on safely.

• Sets BGP max-med high so neighbors prefer other paths.

• Sets all server-facing and egress ports administratively down.

• Waits a configurable settling time for BGP to converge, then copies the running configuration to startup.

• Spines change no ports: only max-med is touched.

Config Pending → Config Ready
Managed Conflict → Managed

Compares the service intents held in SandWork against the device's running configuration.

• Reports anything missing, extra or different.

• Also verifies that the traffic state matches the room: drained in Staging, live in Managed.

• The stage only advances when the device is fully in sync.

Config Ready → Managed

Returns the device to the fabric.

• Clears the max-med penalty.

• Brings ports up according to the service intents: not every port is meant to be up.

• Waits for BGP to converge, then saves the configuration.

Devices here are design records. SandWork holds the intended hostname, role, rack position, device profile and neighbor relationships, but has no credentials or management address, so it cannot reach the hardware.

BLUEPRINT

The only stage in the room. This is where a device first appears and where a decommissioned device returns to.

• InImporting the Data Center plan file; or decommissioning a device from any other stage.

• OutImporting the Inventory file, which supplies management addresses and credentials.

SandWork can now reach the hardware. The job of this room is to confirm that the box in the rack is the box the plan expects, wired as the plan expects. Nothing here carries fabric traffic.

CONNECTED

Reachable, but unverified. Devices in this stage can still complete ZTP / DHCP provisioning.

• InInventory file import; or Finish RMA after a hardware replacement.

• OutPromote to Onboarded. You choose a configuration strategy: push the greenfield configuration, or bypass it for a device already configured out of band.

• FailsThe device stays Connected and the workflow output names the failing check.

ONBOARDED

Reachable and proven to be correctly cabled. The device is trusted enough to begin configuration work.

• InPromote to Onboarded from Connected.

• OutPromote to Config Pending, which drains traffic and hands the device to the Staging room.

• FailsThe device stays Onboarded.

RMA

A device withdrawn from service for physical replacement. Its logical identity, intents and topology position are preserved while the hardware is swapped.

• InStart RMA. From Managed, Managed Conflict or OS Install Failure the traffic is drained first; from other stages the device moves straight across.

• OutFinish RMA records the replacement's MAC address and returns the device to Connected.

The workshop. Service intents (port channels, switchport mappings, network segments, interface speeds) can be created and edited in SandWork here, but they are not pushed to the device until reconciliation runs. Traffic stays drained for the whole stay.

CONFIG_PENDING

The device's configuration is not known to match intent. This is the honest default for anything that has just arrived, just failed, or just been worked on manually.

• InPromote from Onboarded; demote from Managed Conflict; a failed enable traffic from Config Ready; or recovery from OS Install Failure.

• OutPromote to Config Ready by running reconciliation.

• FailsThe device stays Config Pending with the differences listed. Resolve them and promote again.

CONFIG_READY

In sync with intent and ready to serve, but still drained. A device can sit here indefinitely; it is the natural parking place for a switch you are not ready to put into production.

• InSuccessful reconciliation from Config Pending; demote from Managed; or a completed OS upgrade on a device that was in Staging.

• OutPromote to Managed by enabling traffic.

• FailsThe device drops to Config Pending, not back to Config Ready: a half-applied traffic change means the configuration can no longer be assumed in sync.

Production. Service intents are configured on the device as they are created, and the device forwards fabric traffic.

MANAGED

The normal steady state for a data center device. There is no stage beyond this one.

• InPromote from Config Ready; successful reconciliation from Managed Conflict; or a completed OS upgrade on a device that was already Managed.

• OutDemote to Config Ready to take the device out of service for configuration work; Start RMA; or start an OS upgrade.

• FailsIf the demote's traffic drain fails, the device moves to Managed Conflict.

MANAGED_CONFLICT

Still in production and still forwarding traffic, but SandWork has detected that the device's configuration no longer matches intent: from a failed intent push, a failed traffic operation, or a reconciliation run.

• InA detected configuration conflict, or a failed traffic operation on a Managed device.

• OutPromote to Managed once reconciliation passes; or Demote to Config Pending to drain the device and fix it in the Staging room.

• FailsThe device stays in Managed Conflict.

Every transition available in the portal, what it runs, and where the device lands if it fails.

Starting an OS upgrade moves the device into the OS Install room and hands it to the upgrade workflow. This is a detour rather than a step forward: SandWork remembers which room the device came from and returns it there.

• Upgrade succeeds: a device that was in the Managed room returns to MANAGED; anything else returns to CONFIG_READY.

• Upgrade succeeds but post-upgrade reconciliation does not: the device lands in MANAGED_CONFLICT or CONFIG_PENDING respectively, and reconciliation workflows are used to resolve it.

• Upgrade fails: the device sits in OS_INSTALL_FAILURE with the completed and failed upgrade steps listed, and the pre-upgrade configuration snapshot available to download.

From OS_INSTALL_FAILURE you can rerun the upgrade, start an RMA, drain the device into CONFIG_PENDING, or return it to MANAGED. The last option is offered only if the device was in the Managed room before the upgrade began.

Transitions are batch operations: select many devices in a stage tab and promote or demote them together. Each request starts a workflow and returns immediately; the portal raises a notification when it completes, with a per-device breakdown of what succeeded and what did not.

Atomicity is per device. One device failing its cable check does not roll back or block the others in the same request. Each transition also re-validates the device's current stage, so a device that has moved in the meantime is reported as an error rather than acted on.

The two members of an MC-LAG pair have separate staging lifecycles: one can be Connected while its peer is Config Pending, and traffic operations are scoped per device. What is shared is the configuration that depends on both: some service intents (switchport mappings, for instance) are scoped to the pair and need both members in Managed before they can be applied, while others (port speed) are per device.

Decommissioning is the exception: both members of a pair must be decommissioned in the same request.

Decommission returns a device to Blueprint and clears everything learned about the physical unit: hostname, OS record, connection information, management interface addressing, and the greenfield-completed flag. The design record (role, rack position, profile, intents) survives, so the slot can be refilled by importing an Inventory file again.

A device already in Blueprint cannot be decommissioned.