Cinder/blueprints/multi-attach-volume

[ 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:

• 2013-09-25-16.13
• 2013-04-03-16.00

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.
  • Proposal: Volume status = attached when one or more attachments exist, detached when there are no attachments. attaching status on first attach, detaching status on last detach - and/or perhaps move these two values to the attachment level?
• 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?).

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.

GET v1/{tenant_id}/volumes/detail

Changes to detailed volume list to return multiple attachments.

GET v1/{tenant_id}/volumes/{volume_id}

Changes to volume show to return multiple attachments.

GET v1/​{tenant_id}​/volumes/​{volume_id}​

Changes to volume update to handle multiple attachments.