git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


---- On Fri, 24 May 2019 07:02:15 +0900 Matt Riedemann <mriedemos at gmail.com> wrote ----
 > 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/2e85453879533af0b4d0e1178797d26f026a9423/nova/scheduler/utils.py#L528  
 > >  
 > > [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 on option3. For more optimization, can we skip b) and c) for non-baremental case
 assuming if there is Hostmapping then node also will be valid.

-gmann

 >  
 > [1]  
 > http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-05-23-21.00.log.html#l-104 
 >  
 > --  
 >  
 > Thanks, 
 >  
 > Matt 
 >  
 >