A second rack

One design builds every rack in a row. Each rack is its own deployment, and changing one never touches another.

tutorial/compute_rack              one design, in the catalogue
 ├─ rack-r1   rack_name: R1   →   owns rack R1 and everything in it
 └─ rack-r2   rack_name: R2   →   owns rack R2 and everything in it

If you've used Helm, a deployment is a release: one install of a chart, under a name, that you upgrade or uninstall on its own. A Pulumi stack is the same idea.

Deploy it again

1. Select Deploy on tutorial/compute_rack, and choose your NetBox.
2. Leave New deployment selected and name it rack-r2.
3. Set rack_name to R2, and site_slug to riga-dc as before.
4. Select Plan.

This plan creates 260 objects, not 271, and deletes nothing. The 11 it doesn't create are the device types, module types, rack type, roles and manufacturers: they already exist, because rack-r1 created them, so rack-r2 adopts them.

Apply it

Select Apply Changes. In NetBox, the two racks stand side by side in Riga DC.

See what each owns

Select Deployments in the sidebar. It lists every deployment on every NetBox, with its design, its status and how many objects it owns:

• rack-r1 owns 271 and created all of them.
• rack-r2 owns 271 too: it created 260 and adopted the 11 types, roles and manufacturers that rack-r1 created. Hover over the count to see the split.
• site_foundation owns 2, and world_regions owns 7.

Open a deployment to see its sessions, the rounds of planning that applied it. Search and filter the list by design, deploy target and status. View deployments on a NetBox under Deploy Targets, or on a design in the Design Catalogue, opens the list filtered to it.

What a deployment owns decides what it may delete later: only what it created, never what it adopted, and never what another deployment still describes. That rule does the work in the chapters that follow. Deployments states it in full.

Next, change the design and watch a server leave rack R2.