Open Stack

Okay, I was missing that at the point to merge each candidate from each 
request groups, all the rps info in the trees are already in 
ProviderSummaries, and we can use them without an additional query.

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

so I'm good with this and can volunteer it in Placement since this is 
more of general "subtree" thing,

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.

On 2019/05/04 0:03, Eric Fried wrote:
>> It enables something like:
>> * group_resources=1:2:!3:!4
>> which means 1 and 2 should be in the same group but 3 shoudn't be the
>> descendents of 1 or 2, so as 4.
> In a symmetric world, this one is a little ambiguous to me. Does it mean
> 4 shouldn't be in the same subtree as 3 as well?
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?

- 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

-- 
Tetsuro Nakamura <nakamura.tetsuro at lab.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan