<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2019 at 12:16 AM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
1. Omit the validation in the API and let the scheduler do the validation.<br>
<br>
Pros: no performance impact in the API when creating server(s)<br>
<br>
Cons: if the host/node does not exist, the user will get a 202 response <br>
and eventually a NoValidHost error which is not a great user experience, <br>
although it is what happens today with the availability_zone forced <br>
host/node behavior we already have [3] so maybe it's acceptable.<br></blockquote><div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. Validate both the host and node in the API. This can be broken down:<br>
<br>
a) If only host is specified, do #2 above.<br>
b) If only node is specified, iterate the cells looking for the node (or <br>
query a resource provider with that name in placement which would avoid <br>
down cell issues)<br>
c) If both host and node is specified, get the HostMapping and from that <br>
lookup the ComputeNode in the given cell (per the HostMapping)<br>
<br>
Pros: fail fast behavior in the API if either the host and/or node do <br>
not exist<br>
<br>
Cons: performance hit in the API to validate the host/node and <br>
redundancy with the scheduler to find the ComputeNode to get its uuid <br>
for the in_tree filtering on GET /allocation_candidates.<br></blockquote><div> </div><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div></div><div class="gmail_default" style="font-size:small"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Note that if we do find the ComputeNode in the API, we could also <br>
(later?) make a change to the Destination object to add a node_uuid <br>
field so we can pass that through on the RequestSpec from <br>
API->conductor->scheduler and that should remove the need for the <br>
duplicate query in the scheduler code for the in_tree logic.<br><br></blockquote><div> </div><div><br></div><div class="gmail_default" style="font-size:small">I guess we discussed this in a similar(ly different) situation and decided against it [3].</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] <a href="https://github.com/openstack/nova/blob/c7e9e667426a6d88d396a59cb40d30763a3265f9/nova/scheduler/host_manager.py#L660">https://github.com/openstack/nova/blob/c7e9e667426a6d88d396a59cb40d30763a3265f9/nova/scheduler/host_manager.py#L660</a></div><div class="gmail_default" style="font-size:small">[2] <a href="https://github.com/openstack/nova/blob/c7e9e667426a6d88d396a59cb40d30763a3265f9/nova/scheduler/utils.py#L533">https://github.com/openstack/nova/blob/c7e9e667426a6d88d396a59cb40d30763a3265f9/nova/scheduler/utils.py#L533</a></div><div class="gmail_default" style="font-size:small">[3] <a href="https://review.opendev.org/#/c/646029/4/specs/train/approved/use-placement-in-tree.rst@58">https://review.opendev.org/#/c/646029/4/specs/train/approved/use-placement-in-tree.rst@58</a></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br><div>Regards,<br></div><div>Surya.<br></div></div></div></div></div></div>