This message is an attempt to summarize some of the discussions held yesterday during the nova-placement cross project session [1] that were in some way related to the handling of nested providers. There were several individual topics: * NUMA Topology with placement * Subtree affinity with placement * Request group mapping * Resourceless trait filters But they are all closely inter-related, so summarizing the discussion here as a lump. There was some discussion raised about whether representing NUMA topology in placement was worth pursuing as it is not strictly necessary and dang it is sure taking us a long time to get there and will replace an existing set of worms with a new set of worms. The conversation to resolved to: It's worth trying. To make it work there are some adjustments required to how placement operates: * We need to implement a form of the can_split feature (as previously described in [2]) to allow some classes of resource to be satisfied by multiple providers. * The `group_policy=same_tree[...]` concept is needed (as initially proposed in [3]) for affinity (and anti). Some discussion on implementation has started at [4] and there will be in-person discussion in the placement PTG room tomorrow (Saturday) afternoon. * trait and aggregate membership should "flow down" when making any kind of request (numbered or unnumbered). This is closely tied to the implementation of the previous point. * Being able to express 'required' without a 'resources' is required when making an allocation candidates query. * There are several in-flight nova patches where some hacks to flavors are being performed to work around the current lack of this feature. These are okay and safe to carry on with because they are ephemeral. * The number required and resources query parameters need to accept arbitrary strings so it is possible to say things like 'resources_compute' and 'resources_network' to allow conventions to emerge when multiple parties may be involved in manipulating a RequestGroup. * A 'mappings' key will be added to the 'allocations' object in the allocation_candidates response that will support request group mapping. * There will be further discussion on these features Saturday at the PTG starting at 13:30. Actions: * This (Friday) afternoon at the PTG I'll be creating rfe stories associated with these changes. If you'd like to help with that, find me in the placement room (109). We'll work out whether those stories needs specs in the normally processing of the stories. We'll also need to find owners for many of them. * Gibi will be updating the request group mapping spec. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement [2] https://review.opendev.org/#/c/560974/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005673.htm... [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005815.html [5] https://review.opendev.org/#/c/597601/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent