[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
hypervisor.
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.
Best,
-jay
More information about the openstack-discuss
mailing list