Difference between revisions of "Cinder/blueprints/read-only-volumes"
Line 58: | Line 58: | ||
Blueprint: https://blueprints.launchpad.net/cinder/+spec/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 KVM | + | ==== 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 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. | * 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. |
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.