Open Stack

Note: I've changed the subject to make it clear that this thread is
about topics related to resource providers and the placement API
that are not relevant to newton. Ideas that we need to be chewing on
but not things that need to solved now.

On Thu, 28 Jul 2016, Roman Podoliaka wrote:
> I'd personally prefer the latter. I don't think placement api will be
> able to implement all the filters we currently have in
> FilterScheduler.
>
> 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.

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)         http://anticdent.org/
freenode: cdent                                         tw: @anticdent