[
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875335#comment-15875335
]
ASF GitHub Bot commented on CLOUDSTACK-8862:
--------------------------------------------
Github user anshul1886 commented on the issue:
https://github.com/apache/cloudstack/pull/1900
@karuturi @koushik-das @sateesh-chodapuneedi , I had analysed those
failures and working on how to go about those. Issue here is that there are
marvin tests which are for something which was never working. But nobody has
reported any bugs for that.
When we create VM without starting it(startvm=false), then there are
issues. So in this scenario if we try to attach the uploaded volume then its
failing in this PR. But in existing code it is passing successfully i.e. DB
entries are created. Now when we start the VM then we are doing nothing for
uploaded Volume and they always remains in uploaded state and not attached to
VM on hypervisor.
This marvin test is there for ages but nobody has reported any issue
regarding this. So I am currently analysing how to go about this. Is this even
used by Users? Because if they were using this then somebody should have
reported this as this was introduced some five years back. I am thinking of
simple solution which would be to inform user that they have to start vm first
(root volume created) before trying to attach volume.
> 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)
