openstack team mailing list archive

[Brian Schott <bfschott@xxxxxxxxx>]

I'm trying to understand how best to implement our architecture-aware scheduler for Diablo:
https://blueprints.launchpad.net/nova/+spec/schedule-instances-on-heterogeneous-architectures

Right now our scheduler is similar in approach to SimpleScheduler with a few extra filters on instances and compute_nodes table queries for the cpu_arch and xpu_arch fields that we added.  For example, for "-t cg1.4xlarge" GPU instance type the scheduler reads instance_types.cpu_arch="x86_64" and instance_types.xpu_arch = "fermi", then filters the respective compute_node and instance fields.  http://wiki.openstack.org/HeterogeneousInstanceTypes

That's OK for Cactus, but going beyond that, I'm struggling to reconcile these different blueprints:
https://blueprints.launchpad.net/nova/+spec/advanced-scheduler
https://blueprints.launchpad.net/nova/+spec/distributed-scheduler

- How is the instance_metadata table used?  I see the "cpu_arch, xpu_arch" and other fields we added as of the same class of data as vcpus, local_gb, or mem_mb fields, which is why I put them in the instances table.  Virtualization type is of a similar class.  I think of meta-data as less defined constraints passed to the scheduler like "near vol-12345678".

- Will your capabilities scheduler, constraint scheduler, and/or distributed schedulers understand different available hardware resources on compute nodes?

- Should there be an instance_types_metadata table for things like "cpu_arch" rather than our current approach?  

As long as we can inject a "-t cg1.4xlarge" at one end and have that get routed to a compute node with GPU hardware on the other end, we're not tied to the centralized database implementation.

Brian Schott
bfschott@xxxxxxxxx



On Apr 4, 2011, at 7:32 AM, Ed Leafe wrote:

> On Apr 2, 2011, at 10:03 PM, Jagane Sundar wrote:
> 
>> I was wondering if there has been any progress on the following proposal:
>> 
>> http://wiki.openstack.org/RequestCapabilities
>> 
>> I am interested in implementing 'thin provisioning' capability using the framework outlined at the above webpage.
>> This will be for KVM Virtualization initially, perhaps other Virtualization technoloties later on.
>> 
>> Before I go off and write code, I would like to know if there is active development on this proposal, or any interest in 'thin provisioning'.
> 
> 	I'm working on the distributed scheduler (https://blueprints.launchpad.net/nova/+spec/distributed-scheduler), which is the first step in adding the sort of host selection across a complex installation. Sandy Walsh has added the ability for individual hosts to report their capabilities up through the zone hierarchy, where they can be aggregated for more efficient request routing. This will provide the basis for a much more robust means of specifying a host than just "availability zone", which will probably become just one of many potential attributes that one can select for.
> 
> 
> 
> -- Ed Leafe
> 
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse@xxxxxxxxxxxxx, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp