max_over_subscription_ratio is miscalculated for drivers reporting list [True, False] for thin_provisioning
Bug #1578718 reported by
Goutham Pacha Ravi
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Shared File Systems Service (Manila) |
Fix Released
|
High
|
Xing Yang |
Bug Description
For a pool that supports thin_provisioning, the capacity weigher uses the configuration of max_over_
However, currently :https:/
Changed in manila: | |
status: | New → In Progress |
Changed in manila: | |
milestone: | none → newton-rc1 |
Changed in manila: | |
importance: | Medium → High |
Changed in manila: | |
assignee: | Xing Yang (xing-yang) → Goutham Pacha Ravi (gouthamr) |
Changed in manila: | |
assignee: | Goutham Pacha Ravi (gouthamr) → Xing Yang (xing-yang) |
To post a comment you must log in.
Looking at the way the current filter is implemented, this is a fail point for backends that can support both thick/thin shares. If we intend to support both thick/thin, the following changes are necessary: (one way of solving the problem, open for discussion)
1) Make every share_type have a required extra_spec - 'thin_provisioning' (False by default) subscription_ ratio and inflating it as 'adjusted_ free_virtual' in case you are provisioning a 'thin' share. If you are provisioning a thick share, a simple free space check should suffice.
2) Copy this extra_spec into the share model, i.e brand a share as being 'thick' or 'thin'
3) In the Capacity Filter, calculate the sum of sizes of 'thick' shares that have already been accommodated on your pool that supports both 'thick' and 'thin' shares (simple DB call), subtract this from the advertised 'free_space' before multiplying this free_space with the max_over_
Thoughts?