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
