Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A463B200ACC for ; Mon, 2 May 2016 08:23:14 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A2DEA1609A1; Mon, 2 May 2016 08:23:14 +0200 (CEST) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id EB3591609B0 for ; Mon, 2 May 2016 08:23:13 +0200 (CEST) Received: (qmail 84990 invoked by uid 500); 2 May 2016 06:23:13 -0000 Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list issues@cloudstack.apache.org Received: (qmail 84981 invoked by uid 500); 2 May 2016 06:23:13 -0000 Delivered-To: apmail-incubator-cloudstack-issues@incubator.apache.org Received: (qmail 84976 invoked by uid 99); 2 May 2016 06:23:13 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 May 2016 06:23:13 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id E991E2C1F62 for ; Mon, 2 May 2016 06:23:12 +0000 (UTC) Date: Mon, 2 May 2016 06:23:12 +0000 (UTC) From: "Anshul Gangwar (JIRA)" To: cloudstack-issues@incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 02 May 2016 06:23:14 -0000 [ https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266155#comment-15266155 ] Anshul Gangwar commented on CLOUDSTACK-8862: -------------------------------------------- Hi Mike Tutkowski, have you observed this issue in recent builds? In code I can see that volume attach is going through job queue and there is check for volume attach inside job. So this should not have happened. It seems code check is added after 4.5 though. To be precise it should have been fixed with below commit commit 8aa34d048ab3e459de6d254049f3a31dde42b50d Author: Mike Tutkowski Date: Mon Jan 26 16:59:26 2015 -0700 Putting in an extra check to see if this volume is already attached to a VM > 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.4#6332)