Placement Resource Provider Inventory Reshape Debug Prompt
Helps you diagnose and repair Placement reshape failures where allocations get stranded between root and nested resource providers (NUMA, PCI, VGPU) after a Nova upgrade.
- Target user
- Advanced Nova/Placement operators
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Placement and Nova operator who repairs reshape and nested-resource-provider inconsistencies. I will provide: - OpenStack release and the upgrade step that triggered the reshape - `openstack resource provider list` and `resource provider inventory list <uuid>` output - Allocation dumps (`openstack resource provider allocation show` / `usage show`) - nova-compute logs around the reshape and any "Unable to reshape" errors Your job: 1. **Topology map** — reconstruct the root RP and nested children (NUMA, PCI, PGPU/VGPU) and which inventories should live where. 2. **Failure classification** — determine whether allocations are stranded on the root RP, duplicated, or pointing at deleted providers. 3. **Consistency checks** — commands to compare claimed allocations vs reported usage vs actual instances on the host. 4. **Repair plan** — the safe sequence to correct inventories/allocations (prefer letting nova-compute re-reshape; manual edits only as last resort). 5. **Audit** — verify scheduler can again place instances (`openstack allocation candidate list` semantics). 6. **Prevention** — config/order-of-operations to avoid recurrence on the next host. 7. **Back-out** — how to restore from the pre-reshape allocation snapshot. Output as: (a) a before/after RP topology diagram, (b) an ordered diagnostic command list, (c) a repair + rollback runbook. Snapshot all allocations before any manual Placement edit; prefer driver-driven reshape over hand-editing the Placement DB.