[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

It is good to keep user interfaces simple and reduce error (simple in this case comes at the expense of implementation effort)

For the namespace, scope, which hopefully should reduce the likelihood of name clashes
A python package type approach would make sense.  a.b.c.myKey=myValue

-----Original Message-----
From: at [ at] On Behalf Of Joseph Suh
Sent: Friday, August 24, 2012 6:40 PM
To: Patrick Petit
Cc: openstack at (openstack at
Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications


That's a good point. I think the issue is already being discussed at 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.



----- Original Message -----
From: "Patrick Petit" <patrick.michel.petit at>
To: "Joseph Suh" <jsuh at>
Cc: "openstack at (openstack at" <openstack at>, "David Kang" <dkang at>
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?

Envoyé de mon iPad

Le 24 août 2012 à 18:38, Joseph Suh <jsuh at> 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" <dkang at>
> To: "Patrick Petit" <patrick.michel.petit at>
> Cc: "openstack at (openstack at" 
> <openstack at>
> 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
> ----- 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: Post to : 
>> openstack at Unsubscribe : 
>> More help : 
> _______________________________________________
> Mailing list:
> Post to     : openstack at
> Unsubscribe :
> More help   :

Mailing list:
Post to     : openstack at
Unsubscribe :
More help   :