Cinder scheduler's capacity filter is not working as expected when netapp_lun_space_reservation=enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
New
|
Undecided
|
Unassigned |
Bug Description
The backend vserver is iscsi enabled and all the volumes available on this vserver will be considered as pools to provision new iscsi LUNs(Cinder volumes).
Consider there are 5 volumes in this iscsi enabled vserver.
• Vol1 : Free space 500 GB
• Vol2 : Free space 800 GB
• Vol3 : Free space 400 GB
• Vol4 : Free space 100 GB
• Vol5 : Free space 110 GB
When there is a request to create a new LUN of size 450 GB and we know that netapp_
Cinder scheduler is currently whitelisting all the volumes to be used for provisioning a new LUN of size 450 GB.
But as netapp_
Cinder scheduler is checking only if volume_type extra specs has thin provisioning enabled or not, it is also supposed to check if thin provisioning is enabled for the LUNs as well or not.
If thin provisioning is enabled on volume_type extra specs, cinder scheduler is assuming that thin provisioning is enabled for LUNs as well and whitelisting the backend volume in the pool.
max_over_
This behaviour is causing the whitelisting of Vol3,Vol4 and Vol5 and when lun creation is tried with space-reservation enabled it is failing with “No space left on device” error.
This is the capacity filter code where its only checking if thin provisioning is enabled in the volume_type extra specs but not the netapp_
https:/
Information related to netapp_
https:/
netapp_
I think this is a major gap in scheduling and it is causing failures in the creation of most of the cinder volumes with the following error,
2020-01-08 15:50:53.429 55 DEBUG cinder.
<ostype>
<path>
<space-
<use-
<size>
</lun-create-
, 'enable_tunneling': True} trace_logging_
2020-01-08 15:50:53.462 55 DEBUG cinder.