Open Stack

>From the (cross-project) etherpad [1]:

-=-=-
* Spec: https://review.openstack.org/#/c/646029/

* Branch: https://review.openstack.org/#/q/topic:bp/use-placement-in-tree

* -> This spec and branch proposes to translate [user specified
   host/node] into [compute node uuid] internally in nova before asking
   to placement

* Discussion point: What to do when an operator specifies only
   "forced_host" in VM creation with --availability-zone and multiple
   nodes are found in the DB

     1. We use this optimization only when 1 node is found in the nova side DB. Skip this optimization otherwise.

     2. We use this optimization whenever possible passing every found compute node uuids.

     3. We use this optimization when smaller amount than N node are found in the nova side DB. Skip this optimization otherwise.
         3-1. appropriate N value (or the "default" N value) in terms of <REST query string length> and <DB query with IN clause>

     4. Others?

* Note: Option 2 and 3 needs a change in placement side REST API to accept multiple uuids in the `in_tree` query

     * Spec: https://review.openstack.org/#/c/651113/
-=-=-

>From a placement perspective the main discussion point here is the
placement side spec at [2] which is relatively straightforward and
low impact: making an existing query parameter more expressive
while keeping existing response format. There's some questions (on
the spec) about the details of the syntax. There's also a concern
about query string length but that's discussed above.


[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
[2] https://review.openstack.org/#/c/651113/

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent