Open Stack

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



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


[1]
https://github.com/openstack/nova/blob/c7e9e667426a6d88d396a59cb40d30763a3265f9/nova/scheduler/host_manager.py#L660
[2]
https://github.com/openstack/nova/blob/c7e9e667426a6d88d396a59cb40d30763a3265f9/nova/scheduler/utils.py#L533
[3]
https://review.opendev.org/#/c/646029/4/specs/train/approved/use-placement-in-tree.rst@58


-- 

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