For the Deletion issue, it should be ok. Followed is the code in
nova/db/sqlalchemy/api.py to delete the instance type, which will delete the
extra spec table for the corresponding extra_specs also.
Thanks
--jyh
def instance_type_destroy(context, name):
"""Marks specific instance_type as deleted"""
session = get_session()
with session.begin():
instance_type_ref = instance_type_get_by_name(context, name,
session=session)
instance_type_id = instance_type_ref['id']
session.query(models.InstanceTypes).\
filter_by(id=instance_type_id).\
update({'deleted': True,
'deleted_at': timeutils.utcnow(),
'updated_at': literal_column('updated_at')})
session.query(models.InstanceTypeExtraSpecs).\
filter_by(instance_type_id=instance_type_id).\
update({'deleted': True,
'deleted_at': timeutils.utcnow(),
'updated_at': literal_column('updated_at')})
From: Dugger, Donald D
Sent: Saturday, September 08, 2012 5:18 AM
To: Vinay Bannai
Cc: Patrick Petit; Jiang, Yunhong; [email protected]
([email protected])
Subject: RE: [Openstack] [Nova] Instance Type Extra Specs clarifications
OS-FLV-EXTRA-DATA: Do you really need a 17 character scope? Your current
scope (I assume it's a derivative of OpenStack Flavor Extra Data) is really
just redundant info, we know it's extra data for a flavor since we're talking
about the `extra_specs' table which is used for flavors. I would think
something like `disk:qos' would be sufficient, informative and succinct.
Naming consistency: I don't see a real problem here. As long as a unique scope
is used then the actual key names can be arbitrary. Since they are limited to
a specific scope there is no danger of overlap so no need for a naming
convention.
Deletion issues: You raise a good point and I think we should address this.
When a flavor is deleted any `extra_specs' entries for that flavor should be
deleted also. Not a major issue but it would avoid surprises where sale
`extra_specs' could be associated with a new flavor that re-used an ID.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
From: Vinay Bannai [mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: Friday, September 07, 2012 2:41 PM
To: Dugger, Donald D
Cc: Patrick Petit; Jiang, Yunhong;
[email protected]<mailto:[email protected]>
([email protected]<mailto:[email protected]>)
Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
Yes, the intent has been to use something along the lines of
"OS-FLV-EXTRA-DATA:disk_qos"
This leads to another question which I saw being discussed earlier in the email
thread. Are we looking for consistency in adding the extra specs? For the most
obvious ones it may be worth while to come up with a standardized convention
for the names.
I was looking at the code and it appears that the extra_specs and the
instance_types creation don't have similar code flow. When you delete a
instance_type that you created with extra_specs (using the set_key method in
nova-manage), the extra_specs are not cleaned up. I would have thought that
they should go away too, right? Unless I understood the concept of extra_specs
wrong.
Vinay
On Fri, Sep 7, 2012 at 1:27 PM, Dugger, Donald D
<[email protected]<mailto:[email protected]>> wrote:
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<tel:303%2F443-3786>
From: Vinay Bannai [mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, September 07, 2012 2:20 PM
To: Patrick Petit
Cc: Dugger, Donald D;
[email protected]<mailto:[email protected]>
([email protected]<mailto:[email protected]>)
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
<[email protected]<mailto:[email protected]>> wrote:
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
<[email protected]<mailto:[email protected]>>
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<tel:303%2F443-3786>
From:
[email protected]<mailto:[email protected]>
[mailto:openstack-bounces+donald.d.dugger<mailto:openstack-bounces%2Bdonald.d.dugger>[email protected]<mailto:[email protected]>]
On Behalf Of Patrick Petit
Sent: Friday, August 24, 2012 7:13 AM
To: [email protected]<mailto:[email protected]>
([email protected]<mailto:[email protected]>)
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 :
[email protected]<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Vinay Bannai
Email: [email protected]<mailto:[email protected]>
Google Voice: 415 938 7576<tel:415%20938%207576>
--
Vinay Bannai
Email: [email protected]<mailto:[email protected]>
Google Voice: 415 938 7576
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
