From cbf79f05434bf9e3531692e123d03bb218d92bc9 Mon Sep 17 00:00:00 2001 From: xing-yang Date: Sun, 22 May 2016 20:21:57 -0400 Subject: [PATCH] Differentiate thick and thin provisioning If a driver reports thin_provisioning_support to True and thick_provisioning_support to True on a pool that can support both thin and thick volumes, and the user wants to create a thick volume, the current logic in the scheduler would use the wrong logic which makes decisions based on provisioned_capacity_gb and max_over_subscription_ratio. This spec proposes a solution to address the problem. Change-Id: I9d78ee92fac962f69b56a7bc149ee113c1b18b3f Implements: blueprint differentiate-thick-thin-in-scheduler --- .../differentiate-thick-thin-in-scheduler.rst | 155 ++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 specs/newton/differentiate-thick-thin-in-scheduler.rst diff --git a/specs/newton/differentiate-thick-thin-in-scheduler.rst b/specs/newton/differentiate-thick-thin-in-scheduler.rst new file mode 100644 index 00000000..68d25ee9 --- /dev/null +++ b/specs/newton/differentiate-thick-thin-in-scheduler.rst @@ -0,0 +1,155 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +============================================================ +Differentiate thick and thin provisioning logic in scheduler +============================================================ + +Include the URL of your launchpad blueprint: + +https://blueprints.launchpad.net/cinder/+spec/differentiate-thick-thin-in-scheduler + +Currently in the capacity filter and weigher of the scheduler, we use the +logic to evaluate whether there is enough capacity to thin provision a volume +on a backend if the driver reports `thin_provisioning_support` to be True. +However, a driver may be able to support both thin and non-thin provisioning. +The logic does not check whether the user wants the volume to be provisioned +as thin or not. This blueprint proposes to fix the problem by checking +`thick_provisioning_support` in extra specs of the volume type. + +Problem description +=================== + +If a driver reports both `thin_provisioning_support` to True and +`thick_provisioning_support` to True for a pool that can support both thin and +thick luns, and the user wants to create a thick lun, the logic in the +scheduler would wrongly use the logic for thin provisioning to make decisions. +It would make decisions based on `provisioned_capacity_gb` and +`max_over_subscription_ratio`. This could potentially lead to over +provisioning. + +In this spec, we are trying to address this problem by checking whether the +new volume is thin or thick and then use logic accordingly to make decisions. + +Use Cases +========= + +Currently a driver can report both `thin_provisioning_support` to True +and `thick_provisioning_support` to True if it has a pool that can +support both thin and thick. However the logic in the scheduler +checks capacity for thin provisioning if the driver reports +`thin_provisioning_support` to True even if the volume type specifies +the volume to be thick. The proposed spec wants to fix this problem. + +Proposed change +=============== + +The spec proposes to make the following change in the logic in the capacity +filter and the capacity weigher. + +The volume type of the volume to be provisioned will be checked. If +`provisioning_type` is set to `thick` in the extra specs of +the volume type, it will use the thick provisioning logic to evaluate. +Note that this only affects the logic if the driver reports both +`thin_provisioning_support` and `thick_provisioning_support` to True. + +Otherwise, the logic remains the same as before. + +Alternatives +------------ + +None. + +Data model impact +----------------- + +None. + +REST API impact +--------------- + +None. + +Security impact +--------------- + +None. + +Notifications impact +-------------------- + +None. + +Other end user impact +--------------------- + +None. + +Performance Impact +------------------ + +None. + +Other deployer impact +--------------------- + +When the admin sets up volume types, he/she needs to set +the following in the extra specs for a thick volume type:: + +{'thick_provisioning_support': True>} or +{'capabilities:thick_provisioning_support': True>} + +Developer impact +---------------- + +Driver developer should be aware of this extra spec +and handle it accordingly in volume creation. + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + + +Other contributors: + + +Work Items +---------- + +1. Modify capacity filter to check `thick_provisioning_support`. +2. Modify capacity weigher to check `thick_provisioning_support`. + +Dependencies +============ + +None. + +Testing +======= + +Unit tests will be added for this change. + +Documentation Impact +==================== + +Documentation needs to be changed to include this information. + +References +========== + +A patch is proposed in Manila to solve a similar problem: + https://review.openstack.org/#/c/315266/ +Note that capabilities reporting for thin and thick provisioning +in Manila is different from that in Cinder. In Manila, a driver reports +`thin_provisioning = [True, False]` if it supports both thin and thick; +In Cinder, a driver reports `thin_provisioning_support = True` and +`thick_provisioning_support = True` if it supports both thin and thick. +Therefore the proposal in this spec is different from the solution in +the Manila patch.