Open Stack

On 3/14/2019 9:04 AM, Boxiang Zhu wrote:
> The code[4] is now if we specify the force_hosts or force_nodes, 
> scheduler will ignore the filters.

Oh right I always forget that force_hosts/nodes is analogous to the 
force parameter on live migrate and evacuate APIs which is used to 
bypass the scheduler and just use the requested host. Note that we 
removed the force parameters for the live migration and evacuate APIs in 
2.68.

> 
> So I think even we specify the force_hosts or force_nodes, 
> scheduler should evaluate the filters.

Sylvain has talked about make force_hosts/nodes more like cold/live 
migration and evacuate where a host is provided but not forced through 
bypassing the scheduler, and I think that would be a good addition but 
not really with a configuration option - generally we don't want 
config-driven API behavior since it's not interoperable. This is a murky 
area though since force hosts/nodes is an admin API parameter by default 
policy so it's not interoperable by default anyway. A couple of options 
to avoid a config option:

1. Add a new parameter (or couple of parameters) to the server create 
API which would deprecate the weird az:host:node format for forcing a 
host/node and if used, would run the requested destination through the 
scheduler filters. This would be like how cold migrate with a target 
host works today. If users wanted to continue forcing the host and 
bypass the scheduler, they could still use an older microversion with 
the az:host:node format.

2. At the very least, rather than a config option, add a policy rule to 
control whether or not az:host:node (force host/node) bypasses the 
scheduler filters, so some users with certain roles can do that but not 
others. This is not an ideal option though and I'd prefer option 1.

-- 

Thanks,

Matt