cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic
Date Tue, 06 Jun 2017 10:47:18 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16038595#comment-16038595
] 

ASF subversion and git services commented on CLOUDSTACK-8862:
-------------------------------------------------------------

Commit b766bf7fc9787b2516eee2eac6f00dd03a327b8b in cloudstack's branch refs/heads/master from
[~anshulg]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b766bf7 ]

CLOUDSTACK-8862: Introduced new state attaching for volume. This will make sure that other
attach operation on same volume will fail gracefully without calling access calls for managed
storage like SolidFire

Also, skipping test_upload_attach_volume as there is no implementation
which supports this.


> Issuing multiple attach-volume commands simultaneously can be problematic
> -------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8862
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8862
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.5.0, 4.5.1, 4.5.2, 4.6.0
>         Environment: N/A
>            Reporter: Mike Tutkowski
>             Fix For: Future
>
>
> If a user submits two volumeAttach commands around the same time, the first one can succeed
while the second one can fail and can lead CloudStack to ask the underlying storage plug-in
to remove the volume from a given ACL (but the volume should be in the ACL because the first
attachVolume command succeeded).
> A somewhat similar problem can happen if you submit the second attachVolume command to
another VM in the same cluster.
> Proposed solution:
> A data volume should make use of a new column in the volumes table: attach_state (or
some name like that).
> This column can have five possible values: null (for root disks), detached (default state
for data volumes), attaching, attached, and detaching.
> When an attachVolume command is submitted, the volume should immediately be placed into
the "attaching" state. If a transition to that state is not possible, an exception is thrown
(for example, if you're already in the "attached" state, you can't transition to the "attaching"
state).
> A similar kind of logic already exists for volume snapshots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message