[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 20:44:22 UTC 2013

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

>On 29 November 2013 04:50, Gary Kotton <gkotton at vmware.com> wrote:
>> 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
>It still is. We have an existing RPC API in the nova/scheduler tree.
>> One option worth thinking about is to introduce a new scheduling driver
>> nova - this driver will interface with the external scheduler. This will
>> let us define the scheduling API, model etc, without being in the
>> confines of Nova. This will also enable all of the other modules, for
>> example Cinder to hook into it.
>The problem is that that is the boil-the-ocean approach that hasn't
>succeeded for several cycles. We have interest in trying something new
>- there are three failure modes I can see:
>A - we fail to split it out enough, and noone else uses it.
>B - we introduce a performance / correctness problem during the split out
>C - we stall and don't do anything

The first stage is technical - move Nova scheduling code from A to be.
What do we achieve - not much - we actually complicate things - there is
always churn in Nova and we will have duplicate code bases. In addition to
this the only service that can actually make use of they is Nova

The second stage is defining an API that other modules can use (we have
yet to decide if this will be RPC based or have a interface like Glance,
Cinder etc.)
We have yet to even talk about the API's.
The third stage is adding shiny new features and trying to not have a
community tar and feather us.

Prior to copying code we really need to discuss the API's. This can even
be done in parallel if your concern is time and resources. But the point
is we need a API to interface with the service. For a start we can just
address the Nova use case. We need to at least address:
1. Scheduling interface
2. Statistics updates
3. API's for configuring the scheduling policies

Later these will all need to bode well with all of the existing modules
that we want to support - Nova, Cinder and Neutron (if I missed on then
feel free to kick me whilst I am down)

I do not think that we should focus on failure modes, we should plan it
and break it up so that it will be usable and functional and most
importantly useful in the near future.

How about next week we sit together and draw up a wiki of the flows, data
structures and interfaces. Lets go from there.


>Right now, I am mainly worried about B. Getting good APIs is step two
>after getting a solid split out scheduler.
>Robert Collins <rbtcollins at hp.com>
>Distinguished Technologist
>HP Converged Cloud
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list