[ https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857852#comment-15857852 ]
ASF GitHub Bot commented on CLOUDSTACK-8862: -------------------------------------------- Github user ProjectMoon closed the pull request at: https://github.com/apache/cloudstack/pull/1898 > 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)