Sizing capacity rounded volumes
This feature will support storage providers which use a rounding increment to allocate space on the backend. This will prevent the discrepency between what the end user has asked and what is being presented from the backend as a volume Implements: blueprint allocated-size-distinction Change-Id: I5f25aa2eca758a00a7402d1f3b89610aa715eea4
This commit is contained in:
Jean-Pierre Roquesalane
parent
52cf890584
commit
1963171b87
|
|
@ -0,0 +1,152 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=============================
|
||||
Generic backup implementation
|
||||
=============================
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/allocated-size-distinction
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
When creating a volume, Dell PowerFlex will round the value of the capacity by
|
||||
a multiple of 8GB leaving inconsistency between cinder which shows the value
|
||||
requested by the user and powerflex which shows the current allocation.
|
||||
|
||||
This introduces multiple side effects:
|
||||
|
||||
* Allocation capacity not being monitored correctly.
|
||||
* Extension of volume withing the same range will fail as the volume is already
|
||||
at that size (Example: volume extention from 5 to 7, backend already set to 8)
|
||||
* Quota also affected.
|
||||
* Data usage when migrating volumes will be hard to get accurately.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
The main use-case here is when creating or extending a volume with
|
||||
a size which is not a multiplier of an increment size. This is typically the
|
||||
case with Dell PowerFlex storage provider which uses an increment size of 8GB.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
* Add a new field in the database called 'allocated_size'. This size will be the
|
||||
size allocated on the backend and will be the result of the rounding increment
|
||||
|
||||
* The volume is created at the size the user has request and will be shown
|
||||
in two different values. The 'size' which displays the size that cinder is aware
|
||||
of and the 'allocated_size' which displays the size created in the backend
|
||||
|
||||
* The 'allocated_size' is not displayed by default the cinder-client and the
|
||||
information is shown using the '--long' option
|
||||
|
||||
* Add a new field in the API to fetch the 'allocated_size' value
|
||||
|
||||
* The create_volume.py will update the database volume reference according to the
|
||||
computation of the rounded size
|
||||
|
||||
* The manager.py will update the table according to the computation of the rounded
|
||||
size
|
||||
|
||||
* When creating the volume, os-brick will partition the volume in order to provide
|
||||
access to the portion of volume asked by the end-user by using privsep library
|
||||
|
||||
* When extending the volume, os-brick will moodify the partition accordingly
|
||||
|
||||
Vendor-specific changes
|
||||
-----------------------
|
||||
|
||||
Dell PowerFlex driver should be updated to use that new functionality
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Datave everything as it is but the volume size reported by cinder doesn't reflect
|
||||
what's been allocated on the backend. As a side-effect, allocation monitoring is
|
||||
quite hard to follow for end users, extension of capacity can sometimes fail and
|
||||
quota is also affected.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
New field in the cinder/volumes table
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
New field in the API
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Jean-Pierre Roquesalane <jeanpierre.roquesalane@dell.com>
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Modify SQL structure
|
||||
* Implement new logic in cinder
|
||||
* Implement new logic in os-brick/privsep
|
||||
* Unit-tests
|
||||
* Tempest tests
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
* Unit-tests
|
||||
* Tempest tests
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
We will need to update documentation to describe the new capability.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* Antelope PTG https://etherpad.opendev.org/p/antelope-ptg-cinder
|
||||
Loading…
Reference in New Issue