[nova][ptg] Summary: Implicit trait-based filters

Eric Fried openstack at fried.cc
Mon May 6 18:03:27 UTC 2019

In keeping with the first proposed cycle theme [1] (though we didn't
land on that until later in the PTG), we would like to be able to add
required traits to the GET /allocation_candidates query to reduce the
number of results returned - i.e. do more filtering in placement rather
than in the scheduler (or worse, the compute). You can already do this
by explicitly adding required traits to flavor/image; we want to be able
to do it implicitly based on things like:
- If the instance requires multiattach, make sure it lands on a compute
that supports multiattach [2].
- If the image is in X format, make sure it lands on a compute that can
read X format [3].

Currently the proposals in [2],[3] work by modifying the
RequestSpec.flavor right before select_destinations calls GET
/allocation_candidates. This just happens to be okay because we don't
persist that copy of the flavor back to the instance (which we wouldn't
want to do, since we don't want these implicit additions to e.g. show up
when we GET server details, or to affect other lifecycle operations).

But this isn't a robust design.

What we would like to do instead is exploit the
RequestSpec.requested_resources field [4] as it was originally intended,
accumulating all the resource/trait/aggregate/etc. criteria from the
flavor, image, *and* request_filter-y things like the above. However,
gibi started on this [5] and it turns out to be difficult to express the
unnumbered request group in that field for... reasons.

Since gibi is going to be pretty occupied and unlikely to have time to
resolve [5], aspiers has graciously (been) volunteered to take it over;
and then follow [2] and [3] to use that mechanism once it's available.


[2] https://review.opendev.org/#/c/645316/
[5] https://review.opendev.org/#/c/647396/

More information about the openstack-discuss mailing list