[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user ramkatru commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
tag:mergeready


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 416
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=0
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**

**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user sateesh-chodapuneedi commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
LGTM for code changes.
Thanks @anshul1886 for the path.

@karuturi Seems this PR is ready for merge, as it has 2 LGTMs and latest 
test results from @cloudmonger has 0 failures.


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 391
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=0
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**

**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
@anshul1886  can you take a look at the travis and jenkins failures?
volume related tests failed on travis

> 
> 
+--+--+--+--+
> | test_04_deploy_s | Failure  | 15.836   | 
test_stopped_vm  |
> | tartvm_false_att |  |  |
  |
> | ach_volume   |  |  |
  |
> 
+--+--+--+--+
> 
+--+--+--+--+
> | test_06_deploy_s | Failure  | 10.782   | 
test_stopped_vm  |
> | tartvm_attach_de |  |  |
  |
> | tach |  |  |
  |
> 
+--+--+--+--+
> | test_08_deploy_a | Failure  | 21.020   | 
test_stopped_vm  |
> | ttached_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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 358
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=0
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**

**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
Rebased with current master.


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 324
 Hypervisor xenserver
 NetworkType Advanced
 Passed=103
 Failed=1
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* test_routers_network_ops.py

 * test_03_RVR_Network_check_router_state Failed


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_disk_offerings.py


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user ProjectMoon commented on the issue:

https://github.com/apache/cloudstack/pull/1898
  
Closed in favor of #1900 


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


GitHub user anshul1886 reopened a pull request:

https://github.com/apache/cloudstack/pull/1900

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

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8862

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1900.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1900


commit 40d1a82bd9b7e799f269fcfbdfc4ec5923c189b2
Author: Anshul Gangwar 
Date:   2017-01-10T11:40:28Z

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




> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user anshul1886 closed the pull request at:

https://github.com/apache/cloudstack/pull/1900


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


GitHub user anshul1886 reopened a pull request:

https://github.com/apache/cloudstack/pull/1900

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

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8862

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1900.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1900


commit 40d1a82bd9b7e799f269fcfbdfc4ec5923c189b2
Author: Anshul Gangwar 
Date:   2017-01-10T11:40:28Z

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




> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user anshul1886 closed the pull request at:

https://github.com/apache/cloudstack/pull/1900


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
@ProjectMoon Yes it will work fine in clustered scenario as ultimate source 
of truth is DB.


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user ProjectMoon commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
@anshul1886 I have not delved too deeply into the state machine transition 
code, though I understand the basics of how it works. I think `synchronized` + 
state transition should be enough in a single management server scenario, but 
will it work in a clustered scenario? Of course, `synchronized` cannot lock 
across processes, which is why CS has the database locks everywhere. If the 
state transitions will work in a clustered scenario, then I'm fine with just 
using that one.


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
@ProjectMoon We don't need both the commits.  One of the commit is enough. 
Correct me if I am missing something.  And I think using state method is better 
than using lock method.


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user ProjectMoon commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
@anshul1886 I am fine with putting both commits on either PR. If you are 
unopposed we can just stick it on mine?


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
@ProjectMoon @anshul1886  #1898 and #1900 are for the same bug. Can you 
please collaborate and put a single PR?


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1898
  
@ProjectMoon @anshul1886  you are working on the same bug. Can you please 
collaborate and put a single PR?


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


Github user mike-tutkowski commented on the issue:

https://github.com/apache/cloudstack/pull/1900
  
I don't have the resources in my lab available to perform tests on this at 
this time, but the code itself LGTM.

Thanks for working on this JIRA ticket!


> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[Mike Tutkowski (JIRA)]

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

Mike Tutkowski commented on CLOUDSTACK-8862:


Hi [~rajanik] and [~anshulg]

Sorry I missed your comments here. If you have questions still, please let me 
know.

Thanks!

> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


GitHub user anshul1886 opened a pull request:

https://github.com/apache/cloudstack/pull/1900

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

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8862

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1900.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1900


commit 40d1a82bd9b7e799f269fcfbdfc4ec5923c189b2
Author: Anshul Gangwar 
Date:   2017-01-10T11:40:28Z

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




> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8862:


GitHub user ProjectMoon opened a pull request:

https://github.com/apache/cloudstack/pull/1898

CLOUDSTACK-8862: Lock on volume before attempting to attach it.

It is possible to attach a single volume to multiple instances by running 
the commands close to one another. In KVM, this can be verified by checking the 
`virsh dumpxml` for the instances once the volume attaches are complete. This 
PR adds a lock on the volume ID in the orchestration step to make sure the 
method is only executed one at a time for any given volume ID. So in the 
scenario of someone sending simultaneous volume attach requests, one should 
succeed and the others will fail after hitting the check added in 
8aa34d048ab3e459de6d254049f3a31dde42b50d.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/greenqloud/cloudstack pr-volume-sync-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1898.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1898


commit c7d174ceee5e87d5423741923e4f87086d042bd5
Author: jeff 
Date:   2017-01-09T16:28:33Z

CLOUDSTACK-8862: Lock on volume before attempting to attach it.

This commit updates the volume orchestration to lock on the volume ID
before sending the attach commands. While there is already validation
for checking if a VM is already attached to an instance in both the
API command and the volume orchestration framework, they aren't of
much use if there's no synchronization.

With this commit, a single volume being attached to multiple instances
will successfully attach to one and return the error added in commit
8aa34d048ab3e459de6d254049f3a31dde42b50d for the other requests.




> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[Anshul Gangwar (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[Anshul Gangwar (JIRA)]

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

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 after merge of PR 
https://github.com/apache/cloudstack/pull/206.

> 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)

[jira] [Commented] (CLOUDSTACK-8862) Issuing multiple attach-volume commands simultaneously can be problematic

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi commented on CLOUDSTACK-8862:
-

Hi [~mike-tutkowski],  An accidental multiple calls to attachvolume is making 
the volume inaccessible. Is there a work around/setting I could temporarily 
use(on the solidfire or cloudstack end)?  Or atleast recovery steps once this 
happened? 

> 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: 4.6.0
>
>
> 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)