Folsom also supports setting key values for things like capabilities via host aggregates. There is a filter[1] that matches the extra specs by exact comparison just like was done for capabilities before the last patch. The new extra specs matching should be added to it. These capabilities can be set dynamically by administrators so it directly supports the use case below.
[1] https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_instance_extra_specs.py On Aug 24, 2012, at 6:39 PM, Joseph Suh <j...@isi.edu> wrote: > Patrick, > > That's a good point. I think the issue is already being discussed at > https://bugs.launchpad.net/nova/+bug/1039386 as Don Dugger pointed out. > > That being said, as answers to some of your questions: yes, any key/value > pair can be used and it is user's (in this case, system admin's) > responsibility to avoid conflict at this time. The scope we originally > thought was pretty much static like the number of GPUs, but there is no > reason why it should be static as some features can change dynamically. I'd > encourage you to propose a blueprint if you can. We can also consider the > feature, but our team needs to discuss it before we can commit to it. > > Thanks, > > Joseph > > ----- Original Message ----- > From: "Patrick Petit" <patrick.michel.pe...@gmail.com> > To: "Joseph Suh" <j...@isi.edu> > Cc: "openstack@lists.launchpad.net (openstack@lists.launchpad.net)" > <openstack@lists.launchpad.net>, "David Kang" <dk...@isi.edu> > Sent: Friday, August 24, 2012 7:37:31 PM > Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications > > Hi Joseph and All, > > You are pointing the root cause of my question. The question is about how to > specify capabilities for a compute node so that they can be compared with the > extra specs. I think how to define extra specs in a flavor is clear enough. > > So, some capabilities are standard and are generated dynamically. Others are > not known or not captured by the system and so not standard (yet), like the > GPUs, and therefore must be specified somehow. Today, the somehow, as I > understand things, is to add key/value pairs in nova.conf when/if it is > supported. > > I wanted to make sure i understand the basic principals. > > Now, this in my opinion poses couple problems and/or call for additional > questions: > > What is the naming convention to add capabilities in nova.conf? I would > suppose that any key/value pair cannot be taken for a capability. > > How to avoid name clashing with standard capability? At the very least one > should have an option to print them out (in nova-manage?). Even a simple > written list would be helpful. > > But, are we really comfortable with the idea to define static capabilities in > nova.conf? that's putting a lot of burden on config management. Also, not > standard doesn't imply static. > > We can certainly live we that for now, But eventually, i think we'll need > some sort of an extension mechanism so that providers can generate whatever > capabilities they want using their own plugin? Note that capabilities could > be software related too. > > What do you think? > Best, > Patrick > > Envoyé de mon iPad > > Le 24 août 2012 à 18:38, Joseph Suh <j...@isi.edu> a écrit : > >> Patrick, >> >> Once a new item (key and value pair) is added to the capabilities, it can be >> compared against extra_specs. The extra_specs can be populated in >> instance_type_extra_specs table. The items in the extra_specs can start with >> one of the keywords for operations such as ">=" and "s==". For example, if >> "ngpus: 4" is populated in capability, extra_specs of ">= 2" will choose the >> host. If the extra_specs is ">= 5", the host will not be chosen. If no >> keyword is found at the beginning of the extra_specs (with the latest change >> in upstream code), the given string is directly compared with capability. >> For example, if "fpu" is given as extra_specs, the capability must be "fpu" >> to be selected. >> >> If more clarification is needed, please let us know. >> >> Thanks, >> >> Joseph >> >> ----- Original Message ----- >> From: "David Kang" <dk...@isi.edu> >> To: "Patrick Petit" <patrick.michel.pe...@gmail.com> >> Cc: "openstack@lists.launchpad.net (openstack@lists.launchpad.net)" >> <openstack@lists.launchpad.net> >> Sent: Friday, August 24, 2012 11:34:11 AM >> Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications >> >> >> Parick, >> >> We are using the feature in Bare-metal machine provisioning. >> Some keys are automatically generated by nova-compute. >> For example, "hypervisor_type", "hypervisor_version", etc. fields are >> automatically >> put into capabilities by nova-compute (in the case of libvirt). >> So, you don't need to specify that. >> But, if you want to add custom fields, you should put them into nova.conf >> file of >> the nova-compute node. >> >> Since the new key are put into 'capabilities', >> the new key must be different from any other keys in the 'capabilities'. >> If that uniqueness is enforced, it can be any string, I believe. >> >> Thanks, >> David >> >> ---------------------- >> Dr. Dong-In "David" Kang >> Computer Scientist >> USC/ISI >> >> ----- Original Message ----- >>> Hi, >>> >>> >>> Could someone give a practical overview of how configuring and using >>> the instance type extra specs extension capability introduced in >>> Folsom? >>> >>> >>> If how extending an instance type is relatively clear. >>> >>> >>> Eg.: #nova-manage instance_type set_key --name=<my.instancetype> --key >>> <cpu_arch> --value <'s== x86_64'> >>> >>> >>> The principles of capability advertising is less clearer. Is it >>> assumed that the key/value pairs are always declared statically as >>> flags in nova.conf of the compute node, or can they be generated >>> dynamically and if so, who would that be? And also, are the keys >>> completely free form strings or strings that are known (reserved) by >>> Nova? >>> >>> >>> Thanks in advance for clarifying this. >>> >>> >>> Patrick >>> _______________________________________________ >>> 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
