This is the first implementation of scheduler hints for cinderclient. We introduce flexible hint mechanism which enhances user's ability to design filters and interact with them. Cinder already has filter scheduler and a set of filters, but to use them efficiently and to be able to extend existing set of filters one needs mechanism for interacting with them. Scheduler hints may be such a mechanism as they are used this way in nova scheduler, moreover their implementation won't differ much from one for nova scheduler. We found that to be able to add scheduler hints to cinder we need to introduce minor modifications to cinderclient's code and to cinder API. https://blueprints.launchpad.net/cinder/+spec/scheduler-hints
Changed Priority to match upstream
--hint is not in the cinder cli on latest puddle with the below packages [root@cougar06 ~(keystone_admin)]# rpm -qa |grep cinder python-cinderclient-1.0.6-2.el6ost.noarch openstack-cinder-2013.2-2.el6ost.noarch python-cinder-2013.2-2.el6ost.noarch moving back to dev Positional arguments: <size> Size of volume in GB Optional arguments: --snapshot-id <snapshot-id> Create volume from snapshot id (Optional, Default=None) --source-volid <source-volid> Create volume from volume id (Optional, Default=None) --image-id <image-id> Create volume from image id (Optional, Default=None) --display-name <display-name> Volume name (Optional, Default=None) --display-description <display-description> Volume description (Optional, Default=None) --volume-type <volume-type> Volume type (Optional, Default=None) --availability-zone <availability-zone> Availability zone for volume (Optional, Default=None) --metadata [<key=value> [<key=value> ...]] Metadata key=value pairs (Optional, Default=None) [root@cougar06 ~(keystone_admin)]#
$ rpm -q python-cinderclient python-cinderclient-1.0.6-2.el6ost.noarch $ OS_VOLUME_API_VERSION=2 cinder help create ... --metadata [<key=value> [<key=value> ...]] Metadata key=value pairs (Optional, Default=None) --hint <key=value> Scheduler hint like in nova Dafna: this is only available via the Cinder v2 API. The client hides it (even from help) when using v1, which is the default. See the above commands. (Note: this also means you have to have deployed the v2 API endpoint for Cinder.)
I configured the endpoint to v2 and I was able to create using --hint: [root@cougar06 ~(keystone_admin)]# OS_VOLUME_API_VERSION=2 cinder create 10 --name dafna_new --hint dafna=cougar07.scl.lab.tlv.redhat.com +--------------------------------+--------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | created_at | 2013-11-28T13:54:18.000000 | | description | None | | id | 876a0f9b-ec3f-4565-97b2-97c78dc2e559 | | metadata | {} | | name | dafna_new | | os-vol-host-attr:host | cougar06.scl.lab.tlv.redhat.com | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | ddbce226991a45bf97642120207897cb | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | user_id | f40889a38c4644fab9d91b73fcfde1bd | | volume_type | None | +--------------------------------+--------------------------------------+ However, I am not sure how we can check that volume was actually created with the hint.
Eric, Before I move to verify, How can I check that the volume is actually created with the hint?
(In reply to Dafna Ron from comment #11) > Eric, > Before I move to verify, How can I check that the volume is actually created > with the hint? The hint doesn't exist in any fashion after the volume is created -- it's just used by the scheduler for placement, etc. As I had noted before, the schedulers that are built into Cinder don't do anything interesting with these hints outside of using them for volume types (internally). So, I'm not sure what the best thing to test is, outside of using volume types and ensuring that commands like you showed in comment 10 work. You can observe the hint data being passed in the scheduler log if running with debug enabled, but it will not affect anything.
following Eric's reply, since there is nothing more to test here I am moving this bug to verified on API v2 for python-cinder-2013.2-2.el6ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html