Open Stack

And also we should probably deprecate/not recommend:

http://docs.openstack.org/developer/nova/api/nova.scheduler.filters.json_filter.html#nova.scheduler.filters.json_filter.JsonFilter

That filter IMHO basically disallows optimizations like forming SQL 
statements for each filter (and then letting the DB do the heavy 
lifting) or say having each filter say 'oh my logic can be performed by 
a prepared statement ABC and u should just use that instead' (and then 
letting the DB do the heavy lifting).

Chris Friesen wrote:
> On 10/09/2015 12:25 PM, Alec Hothan (ahothan) wrote:
>>
>> Still the point from Chris is valid. I guess the main reason openstack is
>> going with multiple concurrent schedulers is to scale out by
>> distributing the
>> load between multiple instances of schedulers because 1 instance is too
>> slow. This discussion is about coordinating the many instances of
>> schedulers
>> in a way that works and this is actually a difficult problem and will get
>> worst as the number of variables for instance placement increases (for
>> example NFV is going to require a lot more than just cpu pinning, huge
>> pages
>> and numa).
>>
>> Has anybody looked at why 1 instance is too slow and what it would
>> take to
>> make 1 scheduler instance work fast enough? This does not preclude the
>> use of
>> concurrency for finer grain tasks in the background.
>
> Currently we pull data on all (!) of the compute nodes out of the
> database via a series of RPC calls, then evaluate the various filters in
> python code.
>
> I suspect it'd be a lot quicker if each filter was a DB query.
>
> Also, ideally we'd want to query for the most "strict" criteria first,
> to reduce the total number of comparisons. For example, if you want to
> implement the "affinity" server group policy, you only need to test a
> single host. If you're matching against host aggregate metadata, you
> only need to test against hosts in matching aggregates.
>
> Chris
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev