Open Stack

There's movement to move common scheduler code into oslo… at which point it definitely needs to be generic enough to handle the basic functionality of scheduling for both nova and cinder.

There's also discussion about turning the scheduler into its own openstack service… (there may be a blueprint for this already).   As an example, when using volumes with compute, you may want to schedule an instance based on both compute and volume information.  This type of scheduler doesn't belong in nova because volumes live outside.   A new scheduling service that knows about 'all of the things' is needed.  When we have that, how scheduling works in nova changes quite a bit.  Nova would ask the scheduler questions and get responses vs proxying messages via it.

What other topics beside 'compute' are you thinking of below?

- Chris


On 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