openstack team mailing list archive

[Jan Drake <jan_drake@xxxxxxxxxxx>]

If I understand this correctly, the motivation is to be able to provide a hint to schedulers on host-level appropriateness based on information external to that found in the hyperviser. 

Right/Wrong/Close?

It would help to have a real-world example of where basic host resource  evalution for scheduling would cause a situation requiring the host-level hard-coding of what is essentially a flavor-constraint.

I'll hold further thoughts for downstream.


Jan


On Apr 2, 2012, at 6:06 PM, Lorin Hochstein <lorin@xxxxxxxxxxxxxxxxxx> wrote:

> Just created a blueprint for this:
> 
> https://blueprints.launchpad.net/nova/+spec/host-capabilities-api
> 
> 
> Take care,
> 
> Lorin
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
> 
> 
> 
> 
> 
> On Apr 2, 2012, at 3:29 PM, Jay Pipes wrote:
> 
>> Can I add a feature request to the below thoughtstream? Can we make it so that the management of these things can be done outside of config files? i.e. via a REST API with some simple middleware exposing the particular scheduler nodes' understanding of which capabilities/filters it is using to apply its scheduling algorithm?
>> 
>> Making changes to configuration files works OK for simple uses and testing, not so much for on-demand operations :) I say this after grumbling about similar configuration obstacles with ratelimits.
>> 
>> Best,
>> -jay
>> 
>> On 04/02/2012 02:37 PM, Chris Behrens wrote:
>>> I have some plans for being able to set arbitrary "capabilities" for
>>> hosts via nova.conf that you can use to build scheduler filters.
>>> 
>>> Right now, there are capabilities, but I believe we're only creating
>>> these from hypervisor stats. You can filter on those today. What I'm
>>> planning on adding is a way to specify additional keyname/value pairs in
>>> nova.conf to supplement the capabilities we build from hypervisor stats.
>>> You could set things like this in your nova.conf:
>>> 
>>> --host_capabilities=instance_type_ids=1,2,3;keyX;keyY=something
>>> 
>>> etc. Since capabilities are already passed to scheduler rules, you could
>>> add some basic filters that do:
>>> 
>>> if 'instance_type_ids' in capabilities and instance_type.id not in
>>> capabilities['instance_type_ids']:
>>> return False
>>> 
>>> Since host_capabilities are just arbitrary keyname/value pairs, you can
>>> pretty much add anything you want to --host_capabilities and then write
>>> some matching scheduler filter rules.
>>> 
>>> That's the basic idea, anyway. The exact same behavior will apply to
>>> 'cells' and the cells scheduler as well. (Except you'll have
>>> cells_capabilities= somewhere (prob nova.conf for the cells service).
>>> 
>>> - Chris
>>> 
>>> 
>>> On Apr 2, 2012, at 10:36 AM, Day, Phil wrote:
>>> 
>>>> Hi Folks,
>>>> I’m looking for a capability to limit some flavours to some hosts. I
>>>> want the mapping to be as flexible as possible, and work within a
>>>> zone/cell (I don’t want to add zones just to get this mapping). For
>>>> example I want to express something like:
>>>> Host_1 supports flavours A, C
>>>> Host_2 supports flavours A, B
>>>> Host_3 supports flavours A, B, C
>>>> Host_4 supports flavours D
>>>> Ideally there would be some form of grouping to sets of flavours:
>>>> Flavour_A is part of Flavour_Sets 1, 2, 3
>>>> Flavour_B is part of Flavour_Sets 2, 3
>>>> Flavour_C is part of Flavour_Sets 1, 3, 4
>>>> Host_1 supports flavour Set 1
>>>> Host_2 supports flavour Set 2
>>>> Host_3 supports flavour Set 3
>>>> Host_4 supports flavour Set 4
>>>> >From the Essex design summit I thought that host aggregates was going to give this sort of capability, but having looked through the code that seems to be quite tightly coupled with specific hypervisor functionality, whereas this is purely a scheduler feature.
>>>> I can see that I could define flavour group membership through the
>>>> instanace_type_extra_specs, but not how to then associate these with
>>>> specific hosts.
>>>> I know I’m a tad behind some of the recent changes – so before
>>>> suggesting a design summit session on this I thought I’d ask - is
>>>> there something that already does this type of mapping ?
>>>> Cheers,
>>>> Phil
>>>> _______________________________________________
>>>> Mailing list:https://launchpad.net/~openstack
>>>> Post to :openstack@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe :https://launchpad.net/~openstack
>>>> More help :https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp