[nova] Validation for requested host/node on server create

Surya Seetharaman surya.seetharaman9 at gmail.com
Thu May 23 14:46:21 UTC 2019

On Thu, May 23, 2019 at 12:16 AM Matt Riedemann <mriedemos at gmail.com> wrote:

> 1. Omit the validation in the API and let the scheduler do the validation.
> Pros: no performance impact in the API when creating server(s)
> Cons: if the host/node does not exist, the user will get a 202 response
> and eventually a NoValidHost error which is not a great user experience,
> although it is what happens today with the availability_zone forced
> host/node behavior we already have [3] so maybe it's acceptable.

What I had in mind when suggesting this was to actually return a
Host/NodeNotFound exception from the host_manager [1] instead of confusing
that with the NoValidHost exception when its actually not a NoValidHost (as
this is usually associated with host capacity) if the host or node doesn't
exist. I know that it has already been implemented as a NoValidHost [2] but
we could change this.

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

I don't mind if we did this as long as don't hit all the cells twice (in
api and scheduler) which like you said could be avoided by going to

> 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 guess we discussed this in a similar(ly different) situation and decided
against it [3].



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190523/9d5f2230/attachment.html>

More information about the openstack-discuss mailing list