[openstack-dev] [scheduler] Making nova-scheduler extension friendly

David Scannell dscannell at gridcentric.com
Wed Jan 16 16:24:51 UTC 2013


Hi All,

I have been looking into making the nova-scheduler more extension
friendly and in particular expanding it to handle custom topics that
are not 'compute'. The motivation behind this is that we have created
an extension that uses its own manager service with a custom topic,
and we would like to have  nova-scheduler decide the best host for our
request.

Previously we accomplished this by using the open-ended schedule(...)
interface of the nova-scheduler that would take as arguments a topic
and method. Both the ChanceScheduler, and the recently removed
SimpleScheduler, would determine a host and cast a message on the
provided topic for the method. However, it appears that in Folsom this
interface was removed and the scheduler became more focused around the
compute topic.

I would like to make some changes to the scheduler that will allow
extensions builders the ability to create their own drivers to
schedule methods for their topic. As a rough outline here are the
changes I envision:

[a] The drivers are already topic-centric and I would like to
formalize that by having the drivers publish what topic they are
capable of scheduling. The base Scheduler class will have a topic
field and compute-based schedulers (e.g. FilterScheduler or
ChanceScheduler) will set that value to 'compute'. A driver we build
for our extension will set that value to our custom topic.

[b] The manager will be updated to support multiple topic based
drivers instead of a single global one. This can be done by changing
the 'schedule_driver_opt' from a cfg.StrOpt to a cfg.MultiStrOpt and
having the manager build a dictionary of drivers based on the topic
the driver publishes. The main methods in the manager will then use
the driver['compute'] driver for scheduling.

[c] Add a new method to the manager, and rpc client, that extensions
can use to schedule onto their non-compute topic. It would look
something like this:

def schedule(self, context, topic, schedule_method, **kwargs):
    # determine the correct driver to schedule for this topic.
    # ensure that the schedule_method exists on the driver
    # Make a call to the schedule_method on the driver passing in the **kwargs

What would be the best way to get a discussion on this happening?
Should I file an issue or create a blueprint? Any thoughts?

Thanks,
David.



More information about the OpenStack-dev mailing list