d17cc23c64
Due to the fact that certain volume back-ends cannot easily report simple total_capacity_gb/free_capacity_gb for their internal implementation complexity, scheduler is updated to let those back-ends who report unclear capacity pass capacity filter, thus there is chance create_volume() request would fail. In a more general case, when a volume back-end failed to serve create_volume request for whatever reason it'd be good that we have a mechanism to 'retry' the request. So the idea is when volume manager catches the exception from driver.create_volume() call, it checks if the request is allowed to be rescheduled (requests that are not: clone volume and create volume from snapshot while 'snapshot_same_host' option is true), it composes a new request back to scheduler with additional information to mark this specific back-end has been tried (so that scheduler may choose to skip this back-end if needed). Scheduler is (filter scheduler only, simple and chance scheduler is not supported) is updated as well so that it only retry scheduler_max_attempts times. In order to skip/rule out previously tried back-ends in next schedule task, a new RetryFilter is added. Changes: 1) volume RPC API create_volume() is updated with new parameters to save original request information in case rescheduling is needed. This bumps volume RPC API to 1.4. 2) implementation of create_volume() method in volume API is refactored in order to distinguish if a request is allowed to do reschedule (i.e. currently create volume from source volume bypasses scheduler, not rescheduling is allowed). 3) add reschedule functionality in create_volume() of volume manager so that it's able to send the request back to scheduler. 4) add schedule_max_attempts config option in scheduler/driver.py 5) add RetryFitler 6) change scheduler_driver default option to FilterScheduler Change-Id: Ia46b5eb4dc033d73734b6aea82ada34ba5731075
The Choose Your Own Adventure README for Cinder
You have come across a storage service for an open cloud computing service. It has identified itself as "Cinder." It was abstracted from the Nova project.
To monitor it from a distance: follow @openstack on twitter.
To tame it for use in your own cloud: read http://docs.openstack.org
To study its anatomy: read http://cinder.openstack.org
To dissect it in detail: visit http://github.com/openstack/cinder
To taunt it with its weaknesses: use http://bugs.launchpad.net/cinder
To watch it: http://jenkins.openstack.org
To hack at it: read HACKING
To cry over its pylint problems: http://jenkins.openstack.org/job/cinder-pylint/violations