Hi Chris, A really good summary, thank you!
On Thu, Jul 28, 2016 at 4:57 PM, Chris Dent <cdent...@anticdent.org> wrote: > It's pretty clear that were going to need at least an interim and > maybe permanent endpoint that returns a list of candidate target > resource providers. This is because, at least initially, the > placement engine will not be able to resolve all requirements down > to the one single result and additional filtering may be required in > the caller. > > The question is: Will that need for additional filtering always be > present and if so do we: > > * consider that a bad thing that we should strive to fix by > expanding the powers and size of the placement engine > * consider that a good thing that allows the placement engine to be > relatively simple and keeps edge-case behaviors being handled > elsewhere > > If the latter, then we'll have to consider how an allocation/claim > in a list of potential allocations can be essentially reserved, > verified, or rejected. 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 A similar approach could probably be used for assigning weights to RPs when we pass the list of RPs to placement api. Thanks, Roman __________________________________________________________________________ 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