Difference between revisions of "Cinder/blueprints/multi-attach-volume"
< Cinder
(→Blockers) |
|||
| Line 5: | Line 5: | ||
* Contributors: [https://launchpad.net/~kurt-f-martin Kurt Martin], [https://launchpad.net/~lzy-dev Zhi Yan Liu], [https://launchpad.net/~sgordon Stephen Gordon] | * Contributors: [https://launchpad.net/~kurt-f-martin Kurt Martin], [https://launchpad.net/~lzy-dev Zhi Yan Liu], [https://launchpad.net/~sgordon 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 [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. | ||
| Line 17: | Line 17: | ||
* 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 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. | * 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 [https://blueprints.launchpad.net/cinder/+spec/shared-volume 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. | + | * In the discussion of the [https://blueprints.launchpad.net/cinder/+spec/shared-volume 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 Stores = | = User Stores = | ||
= Design = | = 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. | ||
Revision as of 18:58, 26 November 2013
[ 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.
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 Stores
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.
