openstack team mailing list archive

[Brian Schott <bfschott@xxxxxxxxx>]

Thanks!  I have to say tho that we mostly started by coding, then tried to capture what worked as a prototype.

We might be able to use the instance_metadata table for the xpu_info, cpu_info, and net_info fields instead of json strings (although cpu_info was put in by live_migration merge), but our ArchitectureScheduler component needs to filter instances on cpu_arch, xpu_arch, and net_arch fields when summing the consumed resources.  Basically, we need to find a box that has N vcpus of a given architecture, and/or M accelerators in addition in addition to memory and disk (and virtualization).  This is a much more efficient query I think from inside instances.  A sub-select through metadata would be bad.

The scheduler really needs a lot of work to be scalable.  If I understand how SimpleScheduler works, it assumes every compute node in your system has the same number of cores!  

ArchitectureScheduler is comparing vcpus to vcpus_used in compute_nodes table to find resources, although I am concerned our approach might induce a race condition.

Brian

Brian Schott
bfschott@xxxxxxxxx



On Apr 1, 2011, at 6:55 PM, Ferran Rodenas wrote:

> Brian, nice spec! It's a great example of why I appreciate detailed blueprints.
> 
> Although I think it's very interesting to store more information about instance types, I'd be more cautious in creating new columns if it's not strictly necessary. I'd prefer a metadata table, something similar to the instance_metadata table. In this way, each provider can adjust the attributes to their real needs or imagination :)
> 
> - Ferdy
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp