Difference between revisions of "Cinder/blueprints/read-only-volumes"
m (Anastasia Guzikova moved page Cinder/blueprints/read-only to Cinder/blueprints/read-only-volumes) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | * '''Launchpad Entry''': [ | + | * '''Launchpad Entry''': [https://blueprints.launchpad.net/cinder/+spec/read-only-volumes Read-only volumes] |
* '''Created''': 3 July 2013 | * '''Created''': 3 July 2013 | ||
− | * '''Contributors''': Anastasia Guzikova | + | * '''Contributors''': [https://launchpad.net/~aguzikova Anastasia Guzikova] |
== Summary == | == Summary == | ||
Line 14: | Line 14: | ||
The purpose is to provide the ability to attach volumes in the read-only mode. | The purpose is to provide the ability to attach volumes in the read-only mode. | ||
− | + | === immutable volumes === | |
− | + | === cinder as a backend for glance === | |
− | + | https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver | |
− | + | === shared volume === | |
+ | https://blueprints.launchpad.net/cinder/+spec/shared-volume | ||
+ | |||
+ | == Design == | ||
=== How can you use Read Only volumes === | === How can you use Read Only volumes === | ||
+ | Option "permissions" represents volume permissions like file permissions in Unix-like systems | ||
+ | in the format: [0-7][0-7][0-7] | ||
+ | * first digit - user permissions (for the owner) | ||
+ | * second - group permissions (when there will be opportunity to create user groups in keystone) | ||
+ | * third - permissions for others; | ||
+ | digit represents rwx permissions and here: | ||
+ | * r means read permissions as usual, | ||
+ | * w means write permissions as usual, | ||
+ | * x might means permissions to boot from volume. | ||
+ | |||
+ | While multi-RW-attaching is not available, secondary-attach is available in only R/O mode, despite any permissions. | ||
+ | |||
− | Create a Read Only | + | ==== Example ==== |
+ | Create a volume is available in Read/Write mode for the owner and Read Only mode for others. | ||
<pre><nowiki> | <pre><nowiki> | ||
− | |||
POST /v1/<tenant_id>/volumes | POST /v1/<tenant_id>/volumes | ||
Line 31: | Line 46: | ||
"volume": | "volume": | ||
{ | { | ||
− | + | ... | |
− | + | "permissions": "644", | |
− | + | ... | |
− | |||
− | |||
− | |||
− | |||
− | " | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
} | } | ||
} | } | ||
</nowiki></pre> | </nowiki></pre> | ||
− | |||
− | + | === Workflow === | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | == | ||
− | |||
− | == | ||
− | |||
− | |||
'''Read Only volumes''' | '''Read Only volumes''' | ||
+ | Blueprint: https://blueprints.launchpad.net/cinder/+spec/read-only-volumes | ||
− | Add an ability to | + | ==== Add volume permissions support and support of Read Only volume mode (for libvirt initially, i.e. libvirt+KVM, libvirt+xen hypervisors) ==== |
− | Add | + | * an ability to create volume with defined permissions and show volume permissions from CLI and Dashboard, an ability to update volume permissions from CLI; |
+ | * an ability to connect to volume in R/O mode and to see is volume available only in R/O mode or not from CLI and Dashboard. | ||
+ | ==== Add support of Read Only mode for other hypervisors. ==== | ||
+ | TBD | ||
+ | ==== Add ability to configure a user group with group permissions for a volume. ==== | ||
+ | TBD | ||
− | " | + | == Implementation == |
+ | * Add new field "permissions" in cinder database.. | ||
+ | * Add columns "Permissions" and "Read Only" in CLI and Dashboard. | ||
+ | * Add "Permissions" field in volume creation form. | ||
+ | * Add 'readonly' flag in attaching connection conf if volume is Read Only available. | ||
+ | |||
+ | === Code Changes === | ||
− | + | [https://review.openstack.org/#q,topic:bp/read-only-volumes,n,z On review] | |
− | + | Is volume available in only R/O mode checking functionality: | |
+ | <pre><nowiki> | ||
+ | def volume_read_only_get(context, vol): | ||
+ | perms = vol.get('permissions') | ||
+ | RW, RO = False, True | ||
− | == | + | # While no multi-RW-attach, |
+ | # if volume is attached, only R/O mode is available | ||
+ | if vol.get('attach_status') == 'attached': | ||
+ | if vol.get('rw_attached_user') == context.user_id: | ||
+ | return RW | ||
+ | return RO | ||
− | + | if context.user_id == vol.get('user_id'): | |
+ | return int(perms[0]) < 6 | ||
− | + | # TODO(aguzikova): when there will be groups for volumes' users, | |
+ | # check user in group and if it's true use group permissions | ||
− | + | # User in "others" | |
+ | return int(perms[2]) < 6 | ||
+ | </nowiki></pre> | ||
=== Migration === | === Migration === | ||
Line 96: | Line 103: | ||
Include: | Include: | ||
* data migration, if any | * data migration, if any | ||
− | |||
* how users will be pointed to the new way of doing things, if necessary. | * how users will be pointed to the new way of doing things, if necessary. | ||
+ | |||
+ | == Assumptions == | ||
+ | As soon as there will be opportunity to use user groups from keystone, we'll be able to implement functionality with group permissions easily. | ||
== Test/Demo Plan == | == Test/Demo Plan == | ||
Line 104: | Line 113: | ||
== Unresolved issues == | == Unresolved issues == | ||
− | |||
− | |||
− | |||
− | |||
---- | ---- | ||
[[Category:Spec]] | [[Category:Spec]] |
Latest revision as of 08:07, 8 July 2013
- Launchpad Entry: Read-only volumes
- Created: 3 July 2013
- Contributors: Anastasia Guzikova
Contents
Summary
Note this is a big spec and where possible it is broken down into sub-specs to make it easier to share work.
Release Note
Rationale
User stories
The purpose is to provide the ability to attach volumes in the read-only mode.
immutable volumes
cinder as a backend for glance
https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver
https://blueprints.launchpad.net/cinder/+spec/shared-volume
Design
How can you use Read Only volumes
Option "permissions" represents volume permissions like file permissions in Unix-like systems in the format: [0-7][0-7][0-7]
- first digit - user permissions (for the owner)
- second - group permissions (when there will be opportunity to create user groups in keystone)
- third - permissions for others;
digit represents rwx permissions and here:
- r means read permissions as usual,
- w means write permissions as usual,
- x might means permissions to boot from volume.
While multi-RW-attaching is not available, secondary-attach is available in only R/O mode, despite any permissions.
Example
Create a volume is available in Read/Write mode for the owner and Read Only mode for others.
POST /v1/<tenant_id>/volumes body: { "volume": { ... "permissions": "644", ... } }
Workflow
Read Only volumes Blueprint: https://blueprints.launchpad.net/cinder/+spec/read-only-volumes
Add volume permissions support and support of Read Only volume mode (for libvirt initially, i.e. libvirt+KVM, libvirt+xen hypervisors)
- an ability to create volume with defined permissions and show volume permissions from CLI and Dashboard, an ability to update volume permissions from CLI;
- an ability to connect to volume in R/O mode and to see is volume available only in R/O mode or not from CLI and Dashboard.
Add support of Read Only mode for other hypervisors.
TBD
Add ability to configure a user group with group permissions for a volume.
TBD
Implementation
- Add new field "permissions" in cinder database..
- Add columns "Permissions" and "Read Only" in CLI and Dashboard.
- Add "Permissions" field in volume creation form.
- Add 'readonly' flag in attaching connection conf if volume is Read Only available.
Code Changes
Is volume available in only R/O mode checking functionality:
def volume_read_only_get(context, vol): perms = vol.get('permissions') RW, RO = False, True # While no multi-RW-attach, # if volume is attached, only R/O mode is available if vol.get('attach_status') == 'attached': if vol.get('rw_attached_user') == context.user_id: return RW return RO if context.user_id == vol.get('user_id'): return int(perms[0]) < 6 # TODO(aguzikova): when there will be groups for volumes' users, # check user in group and if it's true use group permissions # User in "others" return int(perms[2]) < 6
Migration
Include:
- data migration, if any
- how users will be pointed to the new way of doing things, if necessary.
Assumptions
As soon as there will be opportunity to use user groups from keystone, we'll be able to implement functionality with group permissions easily.
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.