openstack
/
cinder-specs
Code Issues Proposed changes

Update the multiattach spec 

Fix up some minor omissions and clear up some things that may have
changed along the way.

Change-Id: I6832490a914521b957b7605f7affbc565e6b4293
This commit is contained in:
John Griffith 2018-01-11 12:10:39 -07:00
parent fedba17a10
commit 2184d58d9c
1 changed files with 10 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
specs/queens/enable-multiattach.rst
View File

@ -60,6 +60,10 @@ Multi-Attach RW:
Write volumes with no real distinction beyond what's provided with a single
attachment.
The ability to set Read Only options on attachments will be handled as seperate
work in the from of an argument to ``attachment-create``. That feature is
not considered part of the scope of this spec and will be handled independently.
Multi-Attach Capable Backend:
Some backend devices just flat out may not support this. Those that do are
@ -67,30 +71,17 @@ Multi-Attach Capable Backend:
this in their capabilities.
Example Volume Types to communicate Multi Path info:
Read only Multi Attach type (extra-specs)
{
'multiattach': '<is True>',
'mode': 'RO'
}
Read/Write Multi Attach type (extra-specs)
# Default is RW so omission of mode in extra-specs == RW
{
'multiattach': '<is True>',
}
# Also accept explicit request if so desired
{
'multiattach': '<is True>',
'mode': 'RW'
}
It will be up to the Cinder scheduler to determine if the policy allows these
types of volumes to be created, and it will then be up to the driver to form
the corresponding Connection and Volume attributes appropriately in it's
model returns.
Again NOTE we will NOT allow retype of attachment setting for an `in-use`
Again NOTE we will NOT allow retype of multiattachment setting for an `in-use`
volume.
Use Cases
@ -111,10 +102,10 @@ MultiAttach policy
Create a Cinder policy that enables/disables the ability to multi-attach
a volume. This policy is a global policy for the endpoint and simply either
enables or disables the capability. There's no need for any granularity around
RO and RW policies, mostly as these can't be enforced from the Cinder side
anyway. Things like RO and RW will have to be handled by the consuming service
(Nova, Ironic etc).
enables or disables the capability.
Additionally we'll want a specific policy to enable/disable the ability to
multiattach bootable volumes (volume with the bootable parameter set True).
MultiAttach capable volume type
-------------------------------
@ -134,7 +125,7 @@ attachment(s) are left active and NOT interrupted.
To avoid various corner cases and confusion for users in what's allowed and
what's not, this spec proposes we set a hard-code rule that disallows the
retyping of attachment parameters of an `in-use` volume. Regardless of what
those changes are; multi-->non-multi, non-multi-->multi, RO, RW etc etc.
those changes are; multi-->non-multi, non-multi-->multi.
Any retype command should inspect the multiattach keys and if there is any
change being requested in said keys the retype should fail immediately at the