The VPC Tenant Change workflow drives an end-to-end VPC change against a single device: assign the VPC to the device and ports, re-render the tenant configuration, wait for the new render to land in the Config Store, and deploy the rendered configuration to the device. It is the workflow most operators interact with when adding, moving, or expanding a tenant’s footprint on a switch — the underlying VPC Assignment, Render Service, and Tenant Deploy workflows are exposed individually for advanced cases but are normally orchestrated by this workflow.
This workflow is experimental and not intended for general use. Use it only in test or pilot environments.
Before running, confirm:
nv set / nv unset patterns. Changes that escape that scope (touching the default VRF, for example) are refused.After submission, a status page shows the five stages. The workflow runs without human approval; the validation gate is performed inside Tenant Deploy.
The workflow runs five stages in order. None require manual approval.
get_device — Load the target device record from Nautobot.
Resolves the device by UUID and attaches search attributes for observability.
assign_vpc — Run VPC Assignment as a child workflow.
Invokes VPC Assignment with the same inputs to bind the VRF to the device and its ports. If the assignment is a complete no-op (vrf_assigned=false and no assigned_ports changed), the workflow short-circuits — render_tenant_config, wait_for_render, and deploy are marked UNREACHABLE and the workflow exits successfully with device_deployed=null.
render_tenant_config — Trigger a tenant-scoped re-render for the device.
Submits a render request to the render service to generate the updated tenant configuration that reflects the new VRF assignment. The stage captures the resulting tenant_config_file commit ID for tracking.
wait_for_render — Wait for the render to land in the Config Store.
Polls the Config Store for the rendered configuration tagged with the commit ID from the prior stage. Times out if the render service does not produce the file within the configured window.
deploy — Apply the rendered configuration via Tenant Deploy.
Invokes Tenant Deploy as a child workflow against the device. Tenant Deploy performs its own diff validation (allowed nv set patterns only) before applying; a validation failure halts the parent here.
After the workflow reports success, confirm:
assign_vpc green and downstream UNREACHABLE on the no-op path).vrf_assigned, assigned_ports, and vrf in the result reflect the change you intended.device_deployed is the device name when a deploy actually ran; null when the no-op short-circuit fired.Workflow exits with downstream UNREACHABLE.
assign_vpc reported no changes — the VRF was already bound to the device and to all named ports. Successful no-op; the device is already in the desired state.
render_tenant_config or wait_for_render times out.
The render service either rejected the render or is unavailable. Open the Render Service status page; once render is healthy, re-run this workflow.
deploy (Tenant Deploy child) fails with DiffValidationError / StageRuntimeFailure.
The tenant-scoped diff produced by the re-render exceeds the tenant-allowed nv set / nv unset set — for example, a template change snuck in that touches the default VRF. See Tenant Deploy → Diff validation rules. Either restructure the template change so only the tenant scope is affected, or apply the change via Configuration Deploy with a human approval.
get_device_and_vrf (inside the assign_vpc child) raises ApplicationError.
Either zero or multiple VRFs were returned for the vpc_id + namespace_tag combination. Run VPC Creation if the VPC does not exist; reconcile duplicates in Nautobot if it does.
Apply succeeded but the post-deploy backup is missing.
The deploy succeeded; only the backup child failed. Run Configuration Backup against the device once the underlying backup issue is resolved.