openstack team mailing list archive

[David Kang <dkang@xxxxxxx>]

 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp