ComputeCapabilitiesFilter code is convoluted. There are at least 4 different ways it can fail, and 3 of them don't provide any output at all. The one which does logs at debug (should be info), and does not actually provide enough info to diagnose the problem.
The code around here https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L33 and below could do with a nice bit of TLC. For example:
- the for loop on line #49 can only ever be iterating on range(0,1) which is "once", ie no need for a loop.
- the redefinition of "cap" makes it difficult to reason about what data is being worked on.
- the above-mentioned lack of logging.
I recommend checking the strength of the unit tests also, to give confidence that a refactoring doesn't introduce any regressions.
putting into wishlist state because it's not at straight forward 'fix this bug' kind of thing, but more about refactoring. Happy to land patches to clean this up, though in general refactoring like this is valid without bugs as long as we aren't in feature freeze.