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

Khanh-Toan Tran khanh-toan.tran at cloudwatt.com
Fri Nov 29 09:27:58 UTC 2013

> > 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.
> Yup; I look forward to our tar and feathering overlords. :)
> > Prior to copying code we really need to discuss the API's.
> I don't think we do: it's clear that we need to come up with them - it's
> and noone has expressed any doubt about the ability to do that. RPC API
> evolution is fairly well understood - we add a new method, and have it
do the
> necessary, then we go to the users and get them using it, then we delete
the old
> one.
I agree with Robert. I think that nova RPC is fairly enough for the new
right now. Most of the scheduler works focus on nova anyway, so starting
from there 
is reasonable and rather easy for the transition. We can think of
enhancing API later 
(even creating REST API perhaps).

> > 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
> >
If by "2. Statistics update" you mean the database issue for scheduler
then yes, it
is a  big issue, especially during the transition period when nova still
holds the host state
data. Should scheduler get access to nova's DB for the time being, and
later fork out the
DB to scheduler? According to Boris, Merantis has already studied the
separation of host state
from nova's DB. I think we can benefit from their experience.

More information about the OpenStack-dev mailing list