yahoo-eng-team team mailing list archive

[Chris Dent <cdent+lp@xxxxxxxxxxxxx>]

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