Open Stack

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
first).

> 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