On Jul 28, 2016, at 1:19 PM, Chris Dent <cdent...@anticdent.org> wrote:
>> How about we do a query in two steps: >> >> 1) take a list of compute nodes (== resource providers) and apply all >> the filters which *can not* (or *are not* at some point) be >> implemented in placement-api >> >> 2) POST a launch request passing the *pre-filtered* list of resource >> providers. placement api will pick one of those RP, *claim* its >> resources and return the claim info > > While I think the ordering you describe might be useful in the use case > that Ed has described in his message, I think for the general case it is > backwards. We should use the placement API _first_ to winnow out those > hosts that physically cannot satisfy the basic requirements for > inventory of the standard resource classes and then pass that simplified > list to the filters. That ought to be efficient and also provides a path > for easy migration of those filters that can be implemented cleanly in > the placement engine. I can see several use cases where the different approaches result in different efficiencies. Let’s take the Watcher example, as this was the use case that started us down this road. Watcher monitors a data center, and can be configured to migrate VMs to achieve different strategies. One such strategy is packing so that hosts that are not needed can be turned off, saving energy and cooling costs. In this case, Watcher will identify VMs that should be moved, and have a few target hosts that would result in better packing. In a large DC with thousands of hosts, having the placement API go through all those hosts when Watcher only cares about a handful or less is terribly inefficient. In that case, the question that Watcher is asking the placement API is “I need instance X migrated to one of these N hosts. Which of these hosts (if any) are acceptable?”. There are many other scenarios where the opposite would be true, so I wouldn’t want to have it work only one way. IOW, we could change the ‘get_all_hosts’ to ‘get_all_hosts_unless_I_already_have_some_hosts”. :) -- Ed Leafe __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
