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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
