Open Stack

On 08/02/2018 01:12 AM, Alex Xu wrote:
> 2018-08-02 4:09 GMT+08:00 Jay Pipes <jaypipes at gmail.com 
> <mailto:jaypipes at gmail.com>>:
> 
>     On 08/01/2018 02:02 PM, Chris Friesen wrote:
> 
>         On 08/01/2018 11:32 AM, melanie witt wrote:
> 
>             I think it's definitely a significant issue that
>             troubleshooting "No allocation
>             candidates returned" from placement is so difficult.
>             However, it's not
>             straightforward to log detail in placement when the request
>             for allocation
>             candidates is essentially "SELECT * FROM nodes WHERE cpu
>             usage < needed and disk
>             usage < needed and memory usage < needed" and the result is
>             returned from the API.
> 
> 
>         I think the only way to get useful info on a failure would be to
>         break down the huge SQL statement into subclauses and store the
>         results of the intermediate queries.
> 
> 
>     This is a good idea and something that can be done.
> 
> 
> That sounds like you need separate sql query for each resource to get 
> the intermediate, will that be terrible performance than a single query 
> to get the final result?

No, not necessarily.

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.

-jay