openstack team mailing list archive

[Patrick Petit <patrick.michel.petit@xxxxxxxxx>]

Hi Don,

I added a comment in https://bugs.launchpad.net/nova/+bug/1039386 regarding
your point.
Best regards,
Patrick

2012/8/24 Dugger, Donald D <donald.d.dugger@xxxxxxxxx>

>  Patrick-****
>
> ** **
>
> We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries, c.f.
> https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value,
>   You can add an `extra_specs’ key/value pair to a flavor with the command:
> ****
>
> ** **
>
>                 nova-manage instance_type add_key m1.humongous cpu_type
> itanium****
>
> ** **
>
> And delete a key/value pair with the command:****
>
> ** **
>
>                 nova-manage instance_type del_key m1.humongous cpu_type***
> *
>
> ** **
>
> We’re in the process of enhancing `python-novaclient’ and Horizon with
> similar capabilities and hope to have them ready for the Folsom release.**
> **
>
> ** **
>
> Currently, there’s no hook to set `extra_specs’ through the `nova.conf’
> file, the mechanism is to dynamically add the `extra_specs’ key/values
> after the administrator has created a flavor.****
>
> ** **
>
> Currently, the keys are completely free form but there are some issues
> with that so that should change.  Checkout the bug:****
>
> ** **
>
>                 https://bugs.launchpad.net/nova/+bug/1039386****
>
> ** **
>
> Based upon that bug we need to put some sort of scope on the keys to
> indicate which components a key applies to. I’m in favor of adding a new
> column to the `extra_specs’ table that would explicitly set the scope but
> an alternative would be to encode the scope into the key itself, something
> like `TrustedFilter:trust’ to indicate that  the `trust’ key only applies
> to the `TrustedFilter’ scheduler component.  Feel free to chime in on the
> BZ entry on how to specify the scope, once we decide on how to deal with
> this I’ll create a patch to handle it.****
>
> ** **
>
> --****
>
> Don Dugger****
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale****
>
> Ph: 303/443-3786****
>
> ** **
>
> *From:* openstack-bounces+donald.d.dugger=intel.com@xxxxxxxxxxxxxxxxxxx[mailto:
> openstack-bounces+donald.d.dugger=intel.com@xxxxxxxxxxxxxxxxxxx] *On
> Behalf Of *Patrick Petit
> *Sent:* Friday, August 24, 2012 7:13 AM
> *To:* openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx)
> *Subject:* [Openstack] [Nova] Instance Type Extra Specs clarifications****
>
> ** **
>
> 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****
>



-- 
*"Give me a place to stand, and I shall move the earth with a lever"*