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.dug...@intel.com> > 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....@lists.launchpad.net[mailto: > openstack-bounces+donald.d.dugger=intel....@lists.launchpad.net] *On > Behalf Of *Patrick Petit > *Sent:* Friday, August 24, 2012 7:13 AM > *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net) > *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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
