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
bfsch...@gmail.com



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 ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to