Merge "Add spec for per share type quotas"
This commit is contained in:
commit
0e007e65c3
|
@ -0,0 +1,261 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=============================
|
||||
Support quotas per share type
|
||||
=============================
|
||||
|
||||
Blueprint: https://blueprints.launchpad.net/manila/+spec/support-quotas-per-share-type
|
||||
|
||||
Currently, quotas in Manila are configurable on a per tenant and per user
|
||||
basis. They allow admins to set the values for the number of shares,
|
||||
the number of snapshots, or the amount of gigabytes for a project and
|
||||
allow a project member to use resources within these given limits.
|
||||
This spec describes the extension of the current quota scheme: in addition to
|
||||
an overall quota for, say, the number of shares, admins will have
|
||||
the additonal option to define the quota for the number of shares
|
||||
for a given share type. This functionality is similar
|
||||
to the one offered by Cinder for quotas per volume type.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Quotas are meant to help administrators to control the provisioning of
|
||||
available resources, such as the number of shares or the space shares
|
||||
take up on the configured backends. While Manila supports quotas,
|
||||
the current quota scheme does not take share types into account.
|
||||
Considering setups with multiple backends (accessible via different
|
||||
share types), administrators have hence no means to control
|
||||
the resource consumption on the various backends.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
In setups with multiple share-types, per share type quota will allow
|
||||
resource provider to have better control over the provisioned resources.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The proposal is to add per share type quotas in addition to project and
|
||||
user quotas. When a resource is requested, the share type specific quota is
|
||||
checked first. If this check passes, the request is validated against
|
||||
the project/user quota for that resource. It will be possible
|
||||
to set share type quotas only per project, but not per user in scope of
|
||||
single project. It is intended restriction to avoid creation of
|
||||
one more quota layer (third), that will be useful only in case when we need to
|
||||
set different share type quotas for users that are related to
|
||||
one single project.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
An alternative would be to make all share types private, require users
|
||||
to create a new tenant for each share type they'd like to access, and then
|
||||
grant access to the corresponding tenants. This will become impracticable
|
||||
for the users when the number of share types goes up, or when quota schemes
|
||||
for other projects and resources would follow the same approach.
|
||||
|
||||
.. _Cinder's implementation: https://review.openstack.org/#/c/25059/
|
||||
|
||||
Other possible solution is to port `Cinder's implementation`_. Where
|
||||
instead of additional quota layer Cinder creates additional quota
|
||||
resources for each created volume type and names them using following
|
||||
template::
|
||||
|
||||
%RESOURCE_NAME%_%VOLUME_TYPE_NAME%
|
||||
|
||||
But this approach provides two inconveniences:
|
||||
|
||||
* "quota-show" command's response grows with creation of
|
||||
each new share/volume type
|
||||
* names of new share-type-based quota resources can be confusing
|
||||
depending on names of share types. For example, share type 'default' and
|
||||
'shares' quota resource will produce additional quota resource
|
||||
named 'shares_default' in parallel to existing 'shares' project quota
|
||||
resource that is not really intuitive for understanding.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
New share type quotas will have its own DB model similar to existing DB model
|
||||
that is used for "user" quotas with the same relation to "project" quotas.
|
||||
So, it will behave completely the same way as "user quotas". We will have
|
||||
following structure:
|
||||
|
||||
.. graphviz::
|
||||
|
||||
digraph quotas {
|
||||
center=true;
|
||||
|
||||
node_pr [label = "Project Quotas", shape = ellipse, width = 2.2];
|
||||
node_prs[label = "<f0> PROJECT_1|<f1> PROJECT_2|<f2> \.\.|<f3> PROJECT_N", shape = record, fontsize = 10];
|
||||
"node_prs":f0 -> "node_pr" [dir=back];
|
||||
"node_prs":f1 -> "node_pr" [dir=back];
|
||||
"node_prs":f3 -> "node_pr" [dir=back];
|
||||
|
||||
node_u [label = "Users Quotas", shape = ellipse, width = 2.2];
|
||||
node_us[label = "<f0> USER_1|<f1> USER_2|<f2> \.\.|<f3> USER_N", shape = record, fontsize = 10];
|
||||
"node_u" -> "node_us":f0;
|
||||
"node_u" -> "node_us":f1;
|
||||
"node_u" -> "node_us":f3;
|
||||
|
||||
node_st [label = "Share Type Quotas", shape = ellipse, width = 2.2];
|
||||
node_sts[label = "<f0> ST_1|<f1> ST_2|<f2> \.\.|<f3> ST_N", shape = record, fontsize = 10];
|
||||
"node_st" -> "node_sts":f0;
|
||||
"node_st" -> "node_sts":f1;
|
||||
"node_st" -> "node_sts":f3;
|
||||
|
||||
"node_pr" -> "node_u";
|
||||
"node_pr" -> "node_st";
|
||||
}
|
||||
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
Three (3) quota APIs from four (4) will be changed - 'update', 'delete' and
|
||||
'get' API. 'defaults' will stay unchanged and will return project default
|
||||
quotas as they will be default for each share type.
|
||||
All three APIs will start handling additional 'share_type' GET argument,
|
||||
which will be mutually exclusive with existing 'user_id' argument.
|
||||
Response structure will stay the same, with the only exception -
|
||||
quota 'share_networks' will be absent in 'quota-show' response body, because
|
||||
this kind of quota has no value in case of share types. Also, it will not be
|
||||
possible to set/update this quota per share type.
|
||||
New 'share_type' argument should be able to accept both - name and UUID of
|
||||
a share type. API changes will require microversion bump.
|
||||
Old microversions will behave as did before.
|
||||
|
||||
* Get quotas
|
||||
|
||||
* URL: /quota-sets?share_type=%name_or_id%
|
||||
* Method: GET
|
||||
* Response Body::
|
||||
|
||||
{
|
||||
'quota_set': {
|
||||
'shares': -1,
|
||||
'gigabytes': -1,
|
||||
'snapshots': -1,
|
||||
'snapshot_gigabytes': -1,
|
||||
}
|
||||
}
|
||||
|
||||
.. note::
|
||||
|
||||
'share_networks' quota is absent in response,
|
||||
because it is user/project quota only.
|
||||
|
||||
|
||||
* Delete quotas
|
||||
|
||||
* URL: /quota-sets?share_type=%name_or_id%
|
||||
* Method: DELETE
|
||||
|
||||
|
||||
* Update quotas
|
||||
|
||||
* URL: /quota-sets?share_type=%name_or_id%
|
||||
* Method: PUT
|
||||
* JSON body:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
'quotas': {
|
||||
'shares': -1,
|
||||
'gigabytes': -1,
|
||||
'snapshots': -1,
|
||||
'snapshot_gigabytes': -1,
|
||||
}
|
||||
}
|
||||
|
||||
Driver impact
|
||||
-------------
|
||||
|
||||
None.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
The Manila client will get a new optional '--share-type' argument for the
|
||||
'quota-update', 'quota-show' and 'quota-delete' commands,
|
||||
so the modified version of the client will be::
|
||||
|
||||
$ quota-update ... [--share-type <name_or_id>] ... <tenant_id>
|
||||
$ quota-show ... [--share-type <name_or_id>] ... --tenant <tenant_id>
|
||||
$ quota-delete ... [--share-type <name_or_id>] ... --tenant <tenant_id>
|
||||
|
||||
When the '--share-type' argument is omitted, the project quota will be updated,
|
||||
just as now. If the '--share-type' argument is passed, the quota of the
|
||||
corresponding resource(s) for the specified share type will be set.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Additional layer of quota usages calculation will slow down things at
|
||||
some level.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
When creating new share types, the initial quotas for the new share type will
|
||||
be the project quota.
|
||||
Hence, for new tenants, the initial quota must be set for the share types
|
||||
if they shall differ from the project quota.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
Developers of new features that consume quota will need to provide additional
|
||||
"share_type_id" argument to 'reserve', 'commit' and 'rollback' quota commands.
|
||||
Underlying DB layer will handle both quota layers automatically.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
* vponomaryov ( vponomaryov@mirantis.com )
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Server side API changes
|
||||
* Manila Client side changes
|
||||
* Manila UI side changes
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
* unit tests in 'manila', 'python-manilaclient' and 'manila-ui' projects
|
||||
* functional tests in 'manila' and 'python-manilaclient' projects
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
* admin guide: add new '--share-type' parameter to 'update-quota',
|
||||
'quota-show' and 'quota-delete' commands.
|
||||
* devref: reflect the proposed change
|
Loading…
Reference in New Issue