Open Stack

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 at anticdent.org>
> Sent: Sunday, April 28, 2019 10:07 PM
> To: openstack-discuss at 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