Open Stack

> It looks like that this can be done without impacting the performance of
> existing requests that have no queryparam for affinity,

Well, the concern is that doing this at _merge_candidates time (i.e. in
python) may be slow. But yeah, let's not solve that until/unless we see
it's truly a problem.

> but I'd like to say that looking into tracking PCPU feature in Nova and
> see the related problems should precede any Nova related items to model
> NUMA in Placement.

To be clear, placement doesn't need any changes for this. I definitely
don't think we should wait for it to land before starting on the
placement side of the affinity work.

> I thought the negative folks were just refusing to be with in the
> positive folks.
> Looks like there are use cases where we need multiple group_resources?

Yes, certainly eventually we'll need this, even just for positive
affinity. Example: I want two VCPUs, two chunks of memory, and two
accelerators. Each VCPU/memory/accelerator combo must be affined to the
same NUMA node so I can maximize the performance of the accelerator. But
I don't care whether both combos come from the same or different NUMA nodes:

 ?resources_compute1=VCPU:1,MEMORY_MB:1024
 &resources_accel1=FPGA:1
 &same_subtree:compute1,accel1
 &resources_compute2=VCPU:1,MEMORY_MB:1024
 &resources_accel2=FPGA:1
 &same_subtree:compute2,accel2

and what I want to get in return is:

candidates:
 (1) NUMA1 has VCPU:1,MEMORY_MB:1024,FPGA:1; NUMA2 likewise
 (2) NUMA1 has everything
 (3) NUMA2 has everything

Slight aside, could we do this with can_split and just one same_subtree?
I'm not sure you could expect the intended result from:

 ?resources_compute=VCPU:2,MEMORY_MB:2048
 &resources_accel=FPGA:2
 &same_subtree:compute,accel
 &can_split:compute,accel

Intuitively, I think the above *either* means you don't get (1), *or* it
means you can get (1)-(3) *plus* things like:

 (4) NUMA1 has VCPU:2,MEMORY_MB:2048; NUMA2 has FPGA:2

> - I want 1, 2 in the same subtree, and 3, 4 in the same subtree but the
> two subtrees should be separated:
> 
> * group_resources=1:2:!3:!4&group_resources=3:4

Right, and this too.

As a first pass, I would be fine with supporting only positive affinity.
And if it makes things significantly easier, supporting only a single
group_resources per call.

efried
.