Open Stack

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.html
[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