[nova] instance breaks the affinity/anti-affinity of server group with force_hosts or force_nodes
bxzhu_5355 at 163.com
Fri Mar 29 03:07:54 UTC 2019
Wow, It is wonderful. And it's my first time to use the JsonFilter.
At your suggestion and reading the doc, add the JsonFilter to the `filter_scheduler` for `nova.conf`.
Then I used the command like "openstack server create <name> ... --hint query='["=","$host","openstack-node-1"]'.
Great, nova evaluates all the scheduler filters and when it uses the JsonFilter, it only matches the specified host
in query and removes others. :P
BTW, as you mentioned at the early email, the az:host:node format is an admin API.
Maybe we can add a micro version for booting API to evaluate the filters even with
forced_host/forced_node. I have post a draft spec to the nova-spec. If anyone is
convenient, welcome to review and give some comments. : )
On 3/28/2019 22:51，Matt Riedemann<mriedemos at gmail.com> wrote：
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  but it is an existing
alternative if you want to specify a host and still run through the filters.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss