Open Stack

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" <dkang at isi.edu>
To: "Patrick Petit" <patrick.michel.petit at gmail.com>
Cc: "openstack at lists.launchpad.net (openstack at lists.launchpad.net)" <openstack at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp