[placement][nova][ptg] Resource provider - request group mapping

Jay Pipes jaypipes at gmail.com
Sun Apr 21 23:27:25 UTC 2019

On 04/11/2019 07:38 AM, Chris Dent wrote:
> A moment to riff on one the points of having these conversations in
> the expanse of email:
> To my internal unfettered brain the above sort-of-mess is yet more
> evidence that nested is a nightmare and gosh I wish we had never
> done: it, request groups, provider trees on the nova side, and pretty
> much all the stuff that's in progress related to enhanced platform
> awareness. It makes me squirm, see bad smells everywhere, and
> facepalm multiple times per day.

I share your frustration in many ways.

The many "features" added to Nova around NUMA, virtual guest CPU 
topologies, PCI device management/tuning, realtime support, and the 
proposed integration of RMD et al have each eroded the abstraction that 
Nova originally served as: abstraction layer *above* the hardware and 

Ironically, the hierarchical and shared resource providers modeling was 
intended to *ensure* and *promote* a structured, consistent, 
easy-to-reason-about model for resource management.

In other words, the whole idea of placement -- including the addition of 
hierachical and shared providers -- was to provide relief from the 
free-for-all Wild West frontier that still exists in the Nova PCI 
manager, hardware.py module, NUMATopologyFilter, and all that. It was 
supposed to provide us a path out of that quagmire.

I take it as a personal failure that we've yet to be able to take 
advantage of the more consistent and structured data model in placement 
for these more "advanced" resource classes :(

The road to hell is paved with good intentions, I guess.


More information about the openstack-discuss mailing list