Open Stack

Thank you for the suggestions on the topic.
I ended up to add these lines to the RamFilter file "/usr/lib/python2.6/site-packages/nova/scheduler/filters/ram_filter.py":
----
        if usable_ram >= big_ram_node and requested_ram < big_ram_flavor:
            LOG.debug(_("%(host_state)s has %(usable_ram)s MB usable ram,"
                    "which is too much for a %(requested_ram)s MB VM"),
                    locals())
            return False
----

where "big_ram_node" and "big_ram_flavor" are the thresholds I considered for big VMs and big resources.

By this means I beleive it became more flexible, such that, if all the regular nodes were occupied, the small VMs would go on the big nodes.
 


________________________________
 From: Narayan Desai <narayan.desai at gmail.com>
To: Ahmad Ahmadi <ahmadidamha at yahoo.com> 
Cc: "openstack-operators at lists.openstack.org" <openstack-operators at lists.openstack.org> 
Sent: Tuesday, July 2, 2013 7:33 PM
Subject: Re: [Openstack-operators] Instance Scheduling on Hosts
 


We put this in a filter (/usr/share/pyshared/nova/scheduler/filters/hostname_filter.py)

In our case, we have several different classes of hardware. (gpu, idp, mem) We've created a series of instance types for each chassis type (mem.100, idp.50, etc, with the appropriate resource definitions). Our users mostly use these.

I just realized that the basic instance types aren't being filtered from running on special chassis types (mem, and gpu). We haven't hit this so far because we have 50X more IDP nodes than mem or GPU, but we've just been lucky.

To fix that, you could remove the blank lines between clauses and bottom out with a case that enforces that the node name is one of your lowmem nodes for the generic instance types.
 -nld


from nova.scheduler import filters

from nova import log as logging
from nova import utils

LOG = logging.getLogger(__name__)

class HostnameFilter(filters.BaseHostFilter):
    """Assign instance type name prefix to specific hostnames"""

    def host_passes(self, host_state, filter_properties):
        #LOG.warning("Flavor name %s", filter_properties.get('instance_type')['name'].split('.')[0])
        #LOG.warning("host_state %s", host_state)
        #LOG.warning("host name %s", host_state.host)

        if filter_properties.get('instance_type')['name'].split('.')[0] == 'mem':
            if host_state.host.startswith('m',1):
                return True

        if filter_properties.get('instance_type')['name'].split('.')[0] == 'idp':
            if host_state.host.startswith('c',1):
                return True

        if filter_properties.get('instance_type')['name'].split('.')[0] == 'gpu':
            if host_state.host.startswith('g',1):
                return True



On Tue, Jul 2, 2013 at 4:56 PM, Ahmad Ahmadi <ahmadidamha at yahoo.com> wrote:

This is exactly what I'm looking for, but don't know how!
>Would you please describe a bit more?
>
>Thanks
>
>
>________________________________
> From: Narayan Desai <narayan.desai at gmail.com>
>To: Ahmad Ahmadi <ahmadidamha at yahoo.com> 
>Cc: "openstack-operators at lists.openstack.org" <openstack-operators at lists.openstack.org> 
>Sent: Tuesday, July 2, 2013 3:30 PM
>Subject: Re: [Openstack-operators] Instance Scheduling on Hosts
> 
>
>
>We accomplished with a scheduler filter that only routes big mem requests to nodes with large memory footprint and doesn't consider these for smaller instance types.
> -nld
>
>
>
>On Tue, Jul 2, 2013 at 3:55 PM, Ahmad Ahmadi <ahmadidamha at yahoo.com> wrote:
>
>I have two groups of hosts as compute nodes:
>>
>>BigGroup: a few machines with very big RAM
>>SmallGroup: a lot of machines with smaller RAM each.
>>
>>
>>My goal is to assigne bigger instances (from bigger flavors) to BigGroup and smaller instances to SmallGroup.
>>I tried the "AggregateInstanceExtraSpecsFilter" filtering with assigning different keys to instances and making aggregated hosts (http://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html), but didn't work and all the instance boots will end up to error.
>>Any idea?
>>
>>
>>More over does anyone know how can I assign higher cost to bigger nodes for weighting?
>>
>>
>>Thanks,
>>
>>_______________________________________________
>>OpenStack-operators mailing list
>>OpenStack-operators at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130718/50de665c/attachment.html>