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... ? Whichever it is, I think both have merit because they provide a somewhat universal way to interpret trait and aggregate membership, which will help make this stuff more clear. I'm tending to think that resolving this question is the one main things we should do at the PTG, but I'm not clear where to fit it in the schedule without conflicting with a nova topic and also being able to include Jay in the discussion. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent