On Thu, 2 Aug 2018 13:20:43 -0500, Eric Fried wrote:
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.
Okay, but first we should define the actual problem(s) we're trying to
solve, as Chris says, so we can assert that it's worth the (possible)
perf hit and (definite) dev resources, not to mention the potential for
injecting bugs.
The problem is an infamous one, which is, your users are trying to boot
instances and they get "No Valid Host" and an instance in ERROR state.
They contact support, and now support is trying to determine why
NoValidHost happened. In the past, they would turn on DEBUG log level on
the nova-scheduler, try another request, and take a look at the
scheduler logs. They'd see a message, for example, "DiskFilter [start:
2, end: 0]" (there were 2 candidates before DiskFilter ran and there
were 0 after it ran) when the scheduling fails, indicating that
scheduling failed because no computes were reporting enough disk to
fulfill the request. The key thing here is they could see which resource
was not available in their cluster.
Now, with placement, all the resources are checked in one go and support
can't tell which resource or trait was rejected, assuming it wasn't all
of them. They want to know what resource or trait was rejected in order
to help them find the problematic compute host or configuration or other
and fix it.
At present, I think the only approach support could take is to query a
view of resource providers with their resource and trait availability
and compare against the request flavor that failed, to figure out which
resources or traits don't pass what's reported as available.
Hope that helps.
-melanie
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
