[openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

Russell Bryant rbryant at redhat.com
Tue Dec 3 17:58:08 UTC 2013

On 12/03/2013 07:22 AM, Boris Pavlovic wrote:
> Hi all,
> Finally found a bit time to write my thoughts.
> There are few blockers that make really complex to build scheduler as a
> services or even to move main part of scheduler code to separated lib.
> We already have one unsuccessfully effort
> https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler .
> Major problems that we faced were next:
> 1) Hard connection with project db api layer (e.g. nova.db.api,
> cinder.db.api)
> 2) Hard connection between db.models and host_states 
> 3) Hardcoded host states objects structure
> 4) There is no namespace support in host states (so we are not able to
> keep all filters for all projects in the same place)
> 5) Different API methods, that can't be effectively generalized. 
> Main goals of no-db-scheduler effort are: 
> 1) Make scheduling much faster, storing data locally on each scheduler
> and just syncing states of them
> 2) Remove connections between project.db.api and scheduler.db
> 3) Make host_states just JSON like objects
> 4) Add namespace support in host_states 
> When this part will be finished, we will have actually only 1 problem
> what to do with DB API methods, and business logic of each project. What
> I see is that there are 2 different ways:

If the new project is just a forklift of the existing code that still
imports nova's db API and accesses Nova's DB, I don't think the initial
forklift necessarily has to be blocked on completing no-db-scheduler.
That can happen after just as easily (depending on which effort is ready

> 1) Make scheduler as a big lib, then implement RPC methods + bit of
> business logic in each project
> 2) Move all RPC calls from nova,cinder,ironic,... and business logic in
> 1 scheduler as a service 

Right now I think #2 is the approach we should take.  This is mainly
because there is common information that is needed for the scheduling
logic for resources in multiple projects.

Russell Bryant

More information about the OpenStack-dev mailing list