On 5/22/2019 5:13 PM, Matt Riedemann wrote:
3. Validate both the host and node in the API. This can be broken down:
a) If only host is specified, do #2 above. b) If only node is specified, iterate the cells looking for the node (or query a resource provider with that name in placement which would avoid down cell issues) c) If both host and node is specified, get the HostMapping and from that lookup the ComputeNode in the given cell (per the HostMapping)
Pros: fail fast behavior in the API if either the host and/or node do not exist
Cons: performance hit in the API to validate the host/node and redundancy with the scheduler to find the ComputeNode to get its uuid for the in_tree filtering on GET /allocation_candidates.
Note that if we do find the ComputeNode in the API, we could also (later?) make a change to the Destination object to add a node_uuid field so we can pass that through on the RequestSpec from API->conductor->scheduler and that should remove the need for the duplicate query in the scheduler code for the in_tree logic.
I'm personally in favor of option 3 since we know that users hate NoValidHost errors and we have ways to mitigate the performance overhead of that validation.
Note that this isn't necessarily something that has to happen in the same change that introduces the host/hypervisor_hostname parameters to the API. If we do the validation in the API I'd probably split the validation logic into it's own patch to make it easier to test and review on its own.
[1] https://review.opendev.org/#/c/645520/ [2] https://github.com/openstack/nova/blob/2e85453879533af0b4d0e1178797d26f026a9...
[3] https://docs.openstack.org/nova/latest/admin/availability-zones.html
Per the nova meeting today [1] it sounds like we're going to go with option 3 and do the validation in the API - check hostmapping for the host, check placement for the node, we can optimize the redundant scheduler calculation for in_tree later. For review and test sanity I ask that the API validation code comes in a separate patch in the series. [1] http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-05-23-21.00.log.... -- Thanks, Matt