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