On 04/28/2019 07:18 PM, Chris Dent wrote:
On Sun, 21 Apr 2019, Jay Pipes wrote:
In other words, the algorithm for matching allocation candidates should do the following in order for each request group:
1) Find the provider IDs having capacity for the resources contained in the request group 2) If there is a member_of constraint in this request group, reduce the matched set to only those providers that are associated (or have any children associated) with the aggregates listed in the member_of constraint 3) If there is a required trait constraint in this request group, reduce the matched set to only those providers that have the required trait(s) or where their children have the required traits 4) If there is a forbidden trait constraint in this request group, remove from the matched set any providers that have the forbidden trait(s) or where their children have the forbidden traits
Is this the same as or sort of the opposite of the "traits flow down" or "everything is spanning" ideas discussed near
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.htm...
It represents the same idea as "traits flow down". Best, -jay