Open Stack

On 3/14/2019 7:19 AM, Matt Riedemann wrote:
>> 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.

Another alternative for force_hosts/nodes during server create is to use 
the JsonFilter and provide a 'query' scheduler hint where you filter on 
a specific host/node, e.g.:

openstack server create --hint '["=","host","target.host.com"]' ...

Granted, the JsonFilter is not enabled by default and not very well 
tested so we recommend against using it [1] but it is an existing 
alternative if you want to specify a host and still run through the filters.

[1] https://review.openstack.org/#/c/647796/

-- 

Thanks,

Matt