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

Yathiraj Udupi (yudupi) yudupi at cisco.com
Tue Dec 3 19:09:55 UTC 2013

I totally agree on this meta level scheduler aspect. This should separate the placement decision making logic (for resources of any type, but can start on Nova resources) from their actual creation, say VM creation.

This way the placement decisions can be relayed to the individual components "allocator" component or whatever component that handles this after the separation.

So in this effort of separating the scheduler I hope some clean interfaces will be created that separate these logics.  At least we should attempt to make the effort follow some  global meta scheduling clean interfaces that should be designed.


------ Original message------

From: Debojyoti Dutta

Date: Tue, 12/3/2013 10:50 AM

To: OpenStack Development Mailing List (not for usage questions);

Cc: Boris Pavlovic;

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

I agree with RussellB on this … if the forklift's goal is to just separate the scheduler, there should be no new features etc till the forklift is done and it should work as is with very minor config changes.

A scheduler has several features like place resources correctly, for example. Ideally, this should be a simple service that can allocate any resources to any available bucket - balls in bins, VMs in host, blocks/blobs on disk/SSD etc. Maybe the scheduler should operate on meta level resource maps for each "type" and delegate the precise decisions to the allocator for that "type".


On Tue, Dec 3, 2013 at 9:58 AM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:
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

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131203/e95552d0/attachment.html>

More information about the OpenStack-dev mailing list