Difference between revisions of "Cinder/blueprints/multi-attach-volume"
(→volume_attachment.) |
(→Summary) |
||
| Line 9: | Line 9: | ||
Currently the Block Storage (Cinder) service only allow a volume to be attached to one instance at a time. The Compute Service (Nova) also makes assumptions in a number of places to this effect as do the APIs, CLIs, and UIs exposed to users. This specification is drafted in support of [https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume multi-attach-volume] and aims to outline the changes required to allow users to share volumes between multiple guests using either read-write or read-only attachments. | Currently the Block Storage (Cinder) service only allow a volume to be attached to one instance at a time. The Compute Service (Nova) also makes assumptions in a number of places to this effect as do the APIs, CLIs, and UIs exposed to users. This specification is drafted in support of [https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume multi-attach-volume] and aims to outline the changes required to allow users to share volumes between multiple guests using either read-write or read-only attachments. | ||
| − | Comments from a previous proposal to this effect ([https://blueprints.launchpad.net/cinder/+spec/shared-volume shared-volume]) were also taken into consideration. Further background is also available in the etherpad from the [https://etherpad.openstack.org/p/summit-havana-cinder-multi-attach-and-ro-volumes relevant session] at the Portland (Havana) Design Summit. | + | Comments from a previous proposal to this effect ([https://blueprints.launchpad.net/cinder/+spec/shared-volume shared-volume]) were also taken into consideration. Further background is also available in the etherpad from the [https://etherpad.openstack.org/p/summit-havana-cinder-multi-attach-and-ro-volumes relevant session] at the Portland (Havana) Design Summit and these Cinder meeting logs: |
| + | |||
| + | * [http://eavesdrop.openstack.org/meetings/cinder/2013/cinder.2013-09-25-16.13.log.html 2013-09-25-16.13] | ||
| + | * [http://eavesdrop.openstack.org/meetings/cinder/2013/cinder.2013-04-03-16.00.log.html 2013-04-03-16.00] | ||
=Blockers= | =Blockers= | ||
Revision as of 14:38, 27 November 2013
Contents
- 1 [ DRAFT ]
- 2 Summary
- 3 Blockers
- 4 User Stories
- 5 Design
[ DRAFT ]
- Launchpad Entry: https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume
- Created: 25th November 2013
- Contributors: Kurt Martin, Zhi Yan Liu, Stephen Gordon
Summary
Currently the Block Storage (Cinder) service only allow a volume to be attached to one instance at a time. The Compute Service (Nova) also makes assumptions in a number of places to this effect as do the APIs, CLIs, and UIs exposed to users. This specification is drafted in support of multi-attach-volume and aims to outline the changes required to allow users to share volumes between multiple guests using either read-write or read-only attachments.
Comments from a previous proposal to this effect (shared-volume) were also taken into consideration. Further background is also available in the etherpad from the relevant session at the Portland (Havana) Design Summit and these Cinder meeting logs:
Blockers
These issues or questions are outstanding and without resolution will block implementation of this proposal:
- A determination needs to be made with regards to what to resolve the conflict between the overall volume status and the attachment status.
- A determination needs to be made with regards to implementing separation of core and extension functionality within Cinder, allowing multi-attachment to be an extension of core attachment functionality.
- In the discussion of the shared-volume blueprint it was suggested that volumes should have to be explicitly marked as sharable to allow multi-attachment. This is not however the case in the current proposed implementation. Should this be added to help ensure users are aware of the inherent risks of attaching a volume to multiple instances, or is this the responsibility of the client (e.g. Horizon?).
User Stories
Design
Assumptions
- Administrators and users are ultimately responsible for ensuring data integrity is maintained when attaching a shared volume to multiple instances in read-write mode.
Cinder
Database
volume_attachment.
id = Column(String(36), primary_key=True)
user_id = Column(String(255))
project_id = Column(String(255))
volume_id = Column(String(36), ForeignKey('volumes.id'), nullable=False)
instance_uuid = Column(String(36))
attached_host = Column(String(255))
mountpoint = Column(String(255))
attach_time = Column(String(255)) # TODO(vish): datetime
detach_time = Column(String(255)) # TODO(vish): datetime
attach_status = Column(String(255)) # TODO(vish): enum
attach_mode = Column(String(255))
scheduled_at = Column(DateTime)
launched_at = Column(DateTime)
terminated_at = Column(DateTime)
bootable = Column(Boolean, default=False)
API
POST v1/{tenant_id}/volumes/
Changes to volume creation, *if* it is decided that volumes should be explicitly marked as sharable via create/update.
Request
Response
GET v1/{tenant_id}/volumes/detail
Changes to detailed volume list to return multiple attachments.
Request
Response
GET v1/{tenant_id}/volumes/{volume_id}
Changes to volume show to return multiple attachments.
Request
Response
GET v1/{tenant_id}/volumes/{volume_id}
Changes to volume update to handle multiple attachments.
