On 08/02/2018 01:12 AM, Alex Xu wrote:
2018-08-02 4:09 GMT+08:00 Jay Pipes <[email protected]
<mailto:[email protected]>>:
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
