<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 8:24 AM, David Scannell <span dir="ltr"><<a href="mailto:dscannell@gridcentric.com" target="_blank">dscannell@gridcentric.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
I have been looking into making the nova-scheduler more extension<br>
friendly and in particular expanding it to handle custom topics that<br>
are not 'compute'. The motivation behind this is that we have created<br>
an extension that uses its own manager service with a custom topic,<br>
and we would like to have  nova-scheduler decide the best host for our<br>
request.<br>
<br>
Previously we accomplished this by using the open-ended schedule(...)<br>
interface of the nova-scheduler that would take as arguments a topic<br>
and method. Both the ChanceScheduler, and the recently removed<br>
SimpleScheduler, would determine a host and cast a message on the<br>
provided topic for the method. However, it appears that in Folsom this<br>
interface was removed and the scheduler became more focused around the<br>
compute topic.<br>
<br>
I would like to make some changes to the scheduler that will allow<br>
extensions builders the ability to create their own drivers to<br>
schedule methods for their topic. As a rough outline here are the<br>
changes I envision:<br>
<br>
[a] The drivers are already topic-centric and I would like to<br>
formalize that by having the drivers publish what topic they are<br>
capable of scheduling. The base Scheduler class will have a topic<br>
field and compute-based schedulers (e.g. FilterScheduler or<br>
ChanceScheduler) will set that value to 'compute'. A driver we build<br>
for our extension will set that value to our custom topic.<br>
<br>
[b] The manager will be updated to support multiple topic based<br>
drivers instead of a single global one. This can be done by changing<br>
the 'schedule_driver_opt' from a cfg.StrOpt to a cfg.MultiStrOpt and<br>
having the manager build a dictionary of drivers based on the topic<br>
the driver publishes. The main methods in the manager will then use<br>
the driver['compute'] driver for scheduling.<br>
<br>
[c] Add a new method to the manager, and rpc client, that extensions<br>
can use to schedule onto their non-compute topic. It would look<br>
something like this:<br>
<br>
def schedule(self, context, topic, schedule_method, **kwargs):<br>
    # determine the correct driver to schedule for this topic.<br>
    # ensure that the schedule_method exists on the driver<br>
    # Make a call to the schedule_method on the driver passing in the **kwargs<br>
<br>
What would be the best way to get a discussion on this happening?<br>
Should I file an issue or create a blueprint? Any thoughts?<br>
<br>
Thanks,<br>
David.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>