Merge "Support metadata for access rule resource"
This commit is contained in:
Zuul
Gerrit Code Review
commit
4d69ce3206
|
|
@ -0,0 +1,307 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=================================
|
||||
Support metadata for access rule
|
||||
=================================
|
||||
|
||||
https://blueprints.launchpad.net/manila/+spec/metadata-for-access-rule
|
||||
|
||||
Add a new "metadata" property for access rule resource.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Access rule resource lacks the ability for getting/setting metadata property.
|
||||
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
The metadata here for access rule is the descriptive metadata. It's used for
|
||||
discovery and identification. Users could add key-value pairs for the access
|
||||
rules to describe them. Users could also filter access rules with specified
|
||||
metadata while requesting a list of access rules.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
* The "metadata" property will be added to access rule object.
|
||||
* A new DB table "share_access_rules_metadata" will be created.
|
||||
* The access rule create API will be updated to support "metadata".
|
||||
* A set of APIs will be created for access rule metadata's CRUD.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We can only get the desired access rule value by access_to. There is no
|
||||
way to tag what the access rule is by the user or add some special info
|
||||
to access.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
The new "share_access_rules_metadata" table will be created in DB and it
|
||||
will include access rule id. The primary key is "id". We could get
|
||||
information of the access_rules table by the access rule id.
|
||||
|
||||
::
|
||||
|
||||
+-------------------+--------------+-------------+-------------+-----------------+
|
||||
| key | value | id | deleted | access_id |
|
||||
+-------------------+--------------+-------------+-------------+-----------------+
|
||||
| varchar(255) | varchar(255) | varchar(36) | varchar(36) | varchar(36) |
|
||||
+-------------------+--------------+-------------+-------------+-----------------+
|
||||
| varchar(255) | varchar(255) | varchar(36) | varchar(36) | varchar(36) |
|
||||
+-------------------+--------------+-------------+-------------+-----------------+`
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
* It will follow the microversion rules.
|
||||
* The access rule create API's request body will be updated to support "metadata".
|
||||
|
||||
::
|
||||
|
||||
POST /v2/{project_id}/shares/{share_id}/action
|
||||
|
||||
the request body can contain "metadata".
|
||||
{
|
||||
"allow_access":{
|
||||
"metadata":{
|
||||
"key1": "value1",
|
||||
"key2": "value2"
|
||||
}
|
||||
...
|
||||
}
|
||||
}
|
||||
|
||||
* A set of new APIs related to access rule metadata will be created.
|
||||
|
||||
* Show an access rule's metadata
|
||||
|
||||
::
|
||||
|
||||
GET /v2/{project_id}/share-access-rules/{access_id}
|
||||
|
||||
Response
|
||||
{
|
||||
"access": {
|
||||
"access_level": "rw",
|
||||
"state": "error",
|
||||
"id": "507bf114-36f2-4f56-8cf4-857985ca87c1",
|
||||
"access_type": "cert",
|
||||
"access_to": "example.com",
|
||||
"access_key": null,
|
||||
"metadata": {
|
||||
"key1": "value1",
|
||||
"key2": "value2"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
* List access rules filtered by access rule metadata
|
||||
|
||||
::
|
||||
|
||||
GET /v2/{project_id}/share-access-rules?share_id={share-id}&key1=value1&key2=value2
|
||||
|
||||
Response
|
||||
{
|
||||
"accesses": [
|
||||
{
|
||||
"access_level": "rw",
|
||||
"state": "active",
|
||||
"id": "507bf114-36f2-4f56-8cf4-857985ca87c1",
|
||||
"access_type": "cert",
|
||||
"access_to": "example.com",
|
||||
"access_key": null,
|
||||
"metadata": {
|
||||
"key1": "value1",
|
||||
"key2": "value2"
|
||||
}
|
||||
},
|
||||
{
|
||||
"access_level": "rw",
|
||||
"state": "error",
|
||||
"id": "329bf795-2cd5-69s2-cs8d-857985ca3652",
|
||||
"access_type": "ip",
|
||||
"access_to": "10.0.0.2",
|
||||
"access_key": null,
|
||||
"metadata": {
|
||||
"key1": "value1",
|
||||
"key2": "value2"
|
||||
}
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
* The "share_id" is a mandatory query key, and the API will respond with
|
||||
HTTP 400 if the "share_id" is not provided.
|
||||
|
||||
.. note::
|
||||
|
||||
The current `access rules list API
|
||||
<https://developer.openstack.org/api-ref/shared-file-system/#list-access-rules>`_
|
||||
accepts HTTP POST requests. To ensure correct HTTP semantics around
|
||||
idempotent and safe information retrieval, we will introduce a new API that
|
||||
accepts GET requests. The old API will be capped with a maximum micro-version,
|
||||
i.e, it will not be available from the micro-version that this new API is
|
||||
introduced within.
|
||||
|
||||
* Remove one specified metadata
|
||||
|
||||
::
|
||||
|
||||
DELETE /v2/{project_id}/share-access-rules/{access_id}/metadata/{key}
|
||||
|
||||
* If we don't input the "key" value, manila won't remove any metadata and
|
||||
return HTTP 400.
|
||||
|
||||
* Update a specified metadata
|
||||
|
||||
::
|
||||
|
||||
PUT /v2/{project_id}/share-access-rules/{access_id}/metadata
|
||||
|
||||
Request
|
||||
{
|
||||
"metadata":{
|
||||
"key1": "value1",
|
||||
"key2": "value2"
|
||||
}
|
||||
}
|
||||
|
||||
* If we don't input the "key" value, it won't update any metadata
|
||||
and return error.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
The new APIs will send new notifications as well.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
The Manila client, CLI will be extended to support access metadata.
|
||||
|
||||
* The access-allow command with access metadata supported will be like::
|
||||
|
||||
manila access-allow [--metadata <key=value> [<key=value> ...]]
|
||||
[--access-level <access_level>]
|
||||
<share> <access_type> <access_to>
|
||||
|
||||
* The new access-metadata command will be like::
|
||||
|
||||
manila access-metadata <access_id> <action> <key=value> [<key=value> ...]
|
||||
|
||||
Set or delete metadata on a access rule.
|
||||
|
||||
Positional arguments:
|
||||
<access_id> ID of the access rule to update metadata on.
|
||||
<action> Actions: "set" or "unset" to set or delete metadata on a access rule.
|
||||
<key=value> Metadata to set or unset, only key is necessary to unset.
|
||||
|
||||
|
||||
* The new access-show command with access metadata supported will be like::
|
||||
|
||||
manila access-show <access_id>
|
||||
|
||||
Show information of given access rule.
|
||||
|
||||
Positional arguments:
|
||||
<access_id> ID of the access rule to update metadata on.
|
||||
|
||||
|
||||
* The access-deny command will delete all access rule metadata. The command syntax
|
||||
won't be changed::
|
||||
|
||||
manila access-deny <share> <id>
|
||||
|
||||
* The access-list command will add metadata filter. The command will be like::
|
||||
|
||||
manila access-list [--columns <columns>] <share>
|
||||
[--metadata [<key=value> [<key=value> ...]]]
|
||||
Show access list for share.
|
||||
|
||||
Positional arguments:
|
||||
|
||||
<share> Name or ID of the share.
|
||||
|
||||
Optional arguments:
|
||||
|
||||
--columns Comma separated list of columns to be displayed
|
||||
example –columns “access_type,access_to”.
|
||||
|
||||
--metadata Filters results by a metadata key and value.
|
||||
OPTIONAL: Default=None.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
A new "share_access_rules_metadata" table will be created. The DB join action
|
||||
may cause the search performance to reduce on the existing access rules APIs.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
Drivers will not have access to the metadata, and the driver interfaces for
|
||||
update_access will not be modified.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
zhongjun
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add metadata property to access rule object and bump the APIs version.
|
||||
* Create a new DB table "share_access_rules_metadata" and add db upgrade script.
|
||||
* Update access rule create/list API.
|
||||
* Add update/delete APIs for access rule metadata.
|
||||
* Add new tests within openstack/manila-tempest-plugin for the new APIs.
|
||||
* Allow adding/updating/deleting access rule metadata in Manila UI and python-manilaclient.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
* Unit tests
|
||||
* Tempest tests
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
* Api-ref needs update.
|
||||
* update user documentation and CLI documentation
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
Loading…
Reference in New Issue