Hi Chris, Hope you saw my email in this thread on Sat. Using group numbers is not good because [1]: * Request groups from Neutron for bw provider and from Cyborg device profiles will not have explicit group numbers. * Neutron/Cyborg devices should be affined with VCPU/memory, but we shouldn't assume the number of the RG that asks for VCPU/memory. * When those request groups are merged with those from the flavor, the flavor group numbering *could* change. To avoid that, Nova would have to make an explicit guarantee that the Neutron/Cyborg groups get added after the flavor RGs. I am not advocating this. Also, we need some solution for directed affinitizing of specific number of VMs with NUMA nodes, as mentioned in my earlier email. [1] Taken from my comment on https://review.opendev.org/#/c/650476/ Regards, Sundar
-----Original Message----- From: Chris Dent <cdent+os@anticdent.org> Sent: Sunday, April 28, 2019 10:07 PM To: openstack-discuss@lists.openstack.org Subject: Re: [placement][nova][ptg] resource provider affinity
On Sun, 28 Apr 2019, Eric Fried wrote:
We've talked about this previously. The two objections raised were:
a) It assumes the meaning of "same tree" is "one level down from the root".
Does it? I had casually interpreted "group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is somewhere within the tree rooted at $GROUP_A at any level' but it could just as easily be interpreted a few different ways, including what you say.
b) It assumes the various pieces of the request (flavor, image, port, device profile) are able to know each others' request group numbers ahead of time. Or we need provide some other mechanism for the scheduler code that dynamically assigns the numbers [2] to understand which ones need to be (sub)grouped together. IIUC this has been Sundar's main objection.
As I understand things, this is going to be a problem in most of the proposals, for at least one of the many participants in the interactions that lead to a complex workload landing.
Jay suggested extending the JSON schema to allow groups that are names like resources_compute, required_network. That might allow for some conventions to emerge but still requires some measure of knowledge from the participants.
I suspect some form of knowledge is going to be needed. Limiting it would be good.
Also good is making sure that from placement's standpoint the knowledge is merely symbolic.
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent