Customizing the OpenStack Compute (nova) Scheduler

Many OpenStack projects allow for customization of specific features using a driver architecture. You can write a driver that conforms to a particular interface and plug it in through configuration. For example, you can easily plug in a new scheduler for Compute. The existing schedulers for Compute are feature full and well documented at Scheduling. However, depending on your user’s use cases, the existing schedulers might not meet your requirements. You might need to create a new scheduler.

To create a scheduler, you must inherit from the class. Of the five methods that you can override, you must override the two methods marked with an asterisk (*) below:



To demonstrate customizing OpenStack, we’ll create an example of a Compute scheduler that randomly places an instance on a subset of hosts, depending on the originating IP address of the request and the prefix of the hostname. Such an example could be useful when you have a group of users on a subnet and you want all of their instances to start within some subset of your hosts.

When you join the screen session that  starts with , you are greeted with many screen windows:

0$ shell* 1$ key  2$ horizon  ...  9$ n-api  ...  14$ n-sch ...
 * A shell where you can get some work done
 * A shell where you can get some work done


 * The keystone service
 * The keystone service


 * The horizon dashboard web application
 * The horizon dashboard web application


 * The nova services
 * The nova services


 * The nova scheduler service
 * The nova scheduler service

To create the scheduler and plug it in through configuration

 

The code for OpenStack lives in, so go to the   directory and edit your scheduler module. Change to the directory where  is installed: $ cd /opt/stack/nova  

Create the  Python source code file: $ vim nova/scheduler/ip_scheduler.py  

The code shown below is a driver that will schedule servers to hosts based on IP address as explained at the beginning of the section. Copy the code into. When you are done, save and close the file.

There is a lot of useful information in,  , and   that you can use to decide where to schedule the instance. To find out more about what properties are available, you can insert the following log statements into the  method of the scheduler above: LOG.debug(&quot;context = %(context)s&quot; % {'context': context.__dict__}) LOG.debug(&quot;request_spec = %(request_spec)s&quot; % locals) LOG.debug(&quot;filter_properties = %(filter_properties)s&quot; % locals)  

To plug this scheduler into nova, edit one configuration file, : $ vim /etc/nova/nova.conf  

Find the  config and change it like so: scheduler_driver=nova.scheduler.ip_scheduler.IPScheduler  

Restart the nova scheduler service to make nova use your scheduler. Start by switching to the  screen:  Press Ctrl+A followed by 9. Press Ctrl+A followed by N until you reach the  screen.</li> Press Ctrl+C to kill the service.</li> Press Up Arrow to bring up the last command.</li> Press Enter to run it.</li></ol> </li> 

Test your scheduler with the nova CLI. Start by switching to the  screen and finish by switching back to the   screen to check the log output: <ol style="list-style-type: decimal;"> 

Press Ctrl+A followed by 0.</li> 

Make sure you are in the  directory: $ cd /root/devstack </li> 

Source  to set up your environment variables for the CLI: $ . openrc </li> 

Put the image ID for the only installed image into an environment variable: $ IMAGE_ID=`openstack image list | egrep cirros | egrep -v &quot;kernel|ramdisk&quot; | awk '{print $2}'` </li> 

Boot a test server: $ openstack server create --flavor 1 --image $IMAGE_ID scheduler-test </li></ol> </li> 

Switch back to the  screen. Among the log statements, you’ll see the line: 2014-01-23 19:57:47.262 DEBUG nova.scheduler.ip_scheduler [req-... demo demo] Request from xx.xx.xx.xx scheduled to devstack-havana _schedule /opt/stack/nova/nova/scheduler/ip_scheduler.py:76 </li></ol>

A similar pattern can be followed in other projects that use the driver architecture. Simply create a module and class that conform to the driver interface and plug it in through configuration. Your code runs when that feature is used and can call out to other services as necessary. No project core code is touched. Look for a “driver” value in the project’s  configuration files in   to identify projects that use a driver architecture.

When your scheduler is done, we encourage you to open source it and let the community know on the OpenStack mailing list. Perhaps others need the same functionality. They can use your code, provide feedback, and possibly contribute. If enough support exists for it, perhaps you can propose that it be added to the official Compute schedulers.