Placement-backed scheduling in Nova: attributing latency after the Stein and Train transitions

Nova's scheduler has moved from host-side evaluation to Placement-backed candidate selection. Before Stein, the FilterScheduler applied filters and weighers to compute-node state it gathered itself. From Stein (19.0.0) onward, the scheduler requests allocation candidates from the Placement service, which returns a pre-filtered set, and Train (20.0.0) shifted allocation-ratio configuration toward Placement resource-provider inventories.

That transition leaves an unresolved attribution problem. A drop in scheduling throughput can now originate in nova-scheduler's own filtering and weighing, in the Placement API or its database, or in the request pattern itself. Overcommit behavior is also ambiguous during partial upgrades, because allocation ratios may exist both in legacy nova.conf options and in Placement inventories, and it is not always clear which one governs a given resource class. A "No valid host found" result can therefore reflect real capacity exhaustion or a Placement configuration mismatch.

For deployments that have completed this transition, which observable best separates scheduler-side latency from Placement-side latency? How should allocation ratios be reconciled when nova.conf and Placement inventories disagree? And what evidence distinguishes a genuine capacity shortfall from a Placement misconfiguration?