Public bug reported: With the advent of placement, the FilterScheduler no longer provides granular information about which class of resource (disk, VCPU, RAM) is not available in sufficient quantities to allow a host to be found.
This is because placement is now making those choices and does not (yet) break down the results of its queries into easy to understand chunks. If it returns zero results all you know is "we didn't have enough resources". Nothing about which resources. This can be fixed by changing the way in queries are made so that there are a series of queries. After each one a report of how many results are left can be made. While this relatively straightforward to do for the (currently-)common simple non-nested and non-sharing providers situation it will be more difficult for the non-simple cases. Therefore, it makes sense to have different code paths for simple and non-simple allocation candidate queries. This will also result in performance gains for the common case. See this email thread for additional discussion and reports of problems in the wild: http://lists.openstack.org/pipermail/openstack- dev/2018-August/132735.html ** Affects: nova Importance: High Assignee: Jay Pipes (jaypipes) Status: Confirmed ** Tags: placement rocky-rc-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1786519 Title: debugging why NoValidHost with placement challenging Status in OpenStack Compute (nova): Confirmed Bug description: With the advent of placement, the FilterScheduler no longer provides granular information about which class of resource (disk, VCPU, RAM) is not available in sufficient quantities to allow a host to be found. This is because placement is now making those choices and does not (yet) break down the results of its queries into easy to understand chunks. If it returns zero results all you know is "we didn't have enough resources". Nothing about which resources. This can be fixed by changing the way in queries are made so that there are a series of queries. After each one a report of how many results are left can be made. While this relatively straightforward to do for the (currently-)common simple non-nested and non-sharing providers situation it will be more difficult for the non-simple cases. Therefore, it makes sense to have different code paths for simple and non-simple allocation candidate queries. This will also result in performance gains for the common case. See this email thread for additional discussion and reports of problems in the wild: http://lists.openstack.org/pipermail/openstack- dev/2018-August/132735.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1786519/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
