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

Gary Kotton gkotton at vmware.com
Thu Nov 28 15:50:55 UTC 2013

On 11/28/13 12:10 AM, "Robert Collins" <robertc at robertcollins.net> wrote:

>On 25 November 2013 21:51, Sylvain Bauza <sylvain.bauza at bull.net> wrote:
>> As said earlier, I also would love to join the team, triggering a few
>> blueprints or so.
>> By the way, I'm currently reviewing the Scheduler code. Do you began to
>> design the API queries or do you need help for that ?
>> -Sylvain
>is a pre-requisite for nova to use the split out scheduler, but I
>think we can begin before that is complete, by doing the work on the
>new trees:
> - setting up the basic trees we'll need (a service tree and a client
>tree) as openstack-infra/config changes

I am not really sure how we can have a client tree without even having
discussed the API's and interfaces. From the initial round of emails the
intention was to make use of the RPC mechanism to speak with the scheduler.

One option worth thinking about is to introduce a new scheduling driver to
nova - this driver will interface with the external scheduler. This will
let us define the scheduling API, model etc, without being in the current
confines of Nova. This will also enable all of the other modules, for
example Cinder to hook into it.

To be honest I think that that is a lot cleaner way of going about it.
Once the driver is working then we can speak about deprecating the
existing drivers.

My thoughts are:
1. Lets start to define the external scheduler API's - say V1 - support
all existing Nova, Cinder, Neutron etc - that is have parity with these
2. Start to think of the new and shiny scheduling features

How about we draw up a plan for #1 and then see how we can divide up the
work and set milestones etc.

The API's can evolve, but we need to get the initial engine (which will be
based on nova code) up and runningŠ.

Happy holidays

> - picking an interim name (e.g. external-scheduler and
>However, lets get russelb to approve the blueprint
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list