Open Stack

This feels like a blueprint is needed.  I really like the idea of having
multiple, topic based, schedulers.  It would simplify the process greatly
and allow for extensions to be mixed. There will need to be a way to keep
multiple drivers from owning the same topics, however.


On Wed, Jan 16, 2013 at 8:24 AM, David Scannell
<dscannell at gridcentric.com>wrote:

> 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.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130116/fe1cc327/attachment.html>