Difference between revisions of "Cinder/blueprints/multi-attach-volume"
(→Summary: Add etherpad link.) |
(→Blockers) |
||
| Line 11: | Line 11: | ||
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. | ||
| − | == | + | =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 [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. | ||
| + | |||
| + | = User Stores = | ||
| + | |||
| + | = Design = | ||
Revision as of 18:54, 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.
