Open Stack

On 08/02/2018 01:40 PM, Eric Fried wrote:
> Jay et al-
> 
>> And what I'm referring to is doing a single query per "related
>> resource/trait placement request group" -- which is pretty much what
>> we're heading towards anyway.
>>
>> If we had a request for:
>>
>> GET /allocation_candidates?
>>   resources0=VCPU:1&
>>   required0=HW_CPU_X86_AVX2,!HW_CPU_X86_VMX&
>>   resources1=MEMORY_MB:1024
>>
>> and logged something like this:
>>
>> DEBUG: [placement request ID XXX] request group 1 of 2 for 1 PCPU,
>> requiring HW_CPU_X86_AVX2, forbidding HW_CPU_X86_VMX, returned 10 matches
>>
>> DEBUG: [placement request ID XXX] request group 2 of 2 for 1024
>> MEMORY_MB returned 3 matches
>>
>> that would at least go a step towards being more friendly for debugging
>> a particular request's results.
> 
> Well, that's easy [1] (but I'm sure you knew that when you suggested
> it). Produces logs like [2].
> 
> This won't be backportable, I'm afraid.
> 
> [1] https://review.openstack.org/#/c/588350/
> [2] http://paste.openstack.org/raw/727165/

Yes.

And we could do the same kind of approach with the non-granular request 
groups by reducing the single large SQL statement that is used for all 
resources and all traits (and all agg associations) into separate SELECT 
statements.

It could be slightly less performance-optimized but more readable and 
easier to output debug logs like those above.

-jay