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

From a placement perspective the main discussion point here is the

-=-=- * 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/ -=-=- 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