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 <lo...@nimbisservices.com> 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@lists.launchpad.net >>>> <mailto: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 >> >> _______________________________________________ >> 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
