openstack team mailing list archive

[Vinay Bannai <vbannai@xxxxxxxxx>]

Thanks Yunhong,

I picked your changes for flavors.py from your review to give it a try in
my setup. I wrote a little python script to create a flavor id and set_key
using the new RESTful apis that you defined. After creating the flavor,
when I try to set the key I am getting error message from the nova side.
Do I need pick to any changes from nova side to make it work? I can send
you my sample code and error message privately or put it on the mailing
list if that helps.

Vinay

On Sat, Sep 8, 2012 at 6:42 AM, Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>wrote:

>  The extra_specs do have the RESTful interface as
> “/flavors/flavor_type/os-extra_specs”. You can refer to
> https://review.openstack.org/#/c/10768/ for some changes. (I didn’t
> update the patch because I’m recently busy on another task, and will
> restore that patch when I finish current task).****
>
> ** **
>
> Thanks****
>
> --jyh****
>
> ** **
>
> *From:* Dugger, Donald D
> *Sent:* Saturday, September 08, 2012 4:28 AM
> *To:* Vinay Bannai; Patrick Petit; Jiang, Yunhong
> *Cc:* openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx)
> *Subject:* RE: [Openstack] [Nova] Instance Type Extra Specs clarifications
> ****
>
> ** **
>
> Well, Yunhong added the API to allow you to update the extra specs table
> so he should be able to give you the details on that (he’s in China, he
> might not get back to you until next week).****
>
> ** **
>
> Also, make sure you add a scope (where scope is a string followed by a `:’
> at the beginning of the key) to whatever key you are adding to the extra
> specs table, otherwise your key will create problems with some of the
> scheduler filters.****
>
> ** **
>
> --****
>
> Don Dugger****
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale****
>
> Ph: 303/443-3786****
>
> ** **
>
> *From:* Vinay Bannai [mailto:vbannai@xxxxxxxxx]
> *Sent:* Friday, September 07, 2012 2:20 PM
> *To:* Patrick Petit
> *Cc:* Dugger, Donald D; openstack@xxxxxxxxxxxxxxxxxxx (
> openstack@xxxxxxxxxxxxxxxxxxx)
> *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
> ****
>
> ** **
>
> Hello all,****
>
> ** **
>
> I am part of the SF south bay meetup group and trying to add a Disk I/O
> QoS feature which is based on the blkiotune in libvirt. ****
>
> We would like to add flavor types in which we specify the blkiotune in the
> create flavor screen. After reviewing the discussions and some emails it
> appears that it makes sense to use the "instance_type_extra_specs" to add
> the blkiotune as a key/value pair instead of extending the "instance_type"
> table in nova db. ****
>
> ** **
>
> I am able to use nova-manage to create instance type and use "set_key" to
> add extra specs. The set_key seems to make a direct call to the db to
> insert the keys whereas the instance_type create takes the more traditional
> path through the flavomanage controller. However I notice that there is no
> documentation on how to add the extra_specs keys using a RESTful api. Is
> this something still in discussions? ****
>
> ** **
>
> Thanks****
>
> Vinay****
>
> ** **
>
> On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit <
> patrick.michel.petit@xxxxxxxxx> wrote:****
>
> Hi Don,****
>
> ** **
>
> I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding 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"*****
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp****
>
>
>
> ****
>
> ** **
>
> --
> Vinay Bannai
> Email: vbannai@xxxxxxxxx
> Google Voice: 415 938 7576****
>



-- 
Vinay Bannai
Email: vbannai@xxxxxxxxx
Google Voice: 415 938 7576