[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
thank you sir.  :)


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
@blueorangutan test


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-594


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep 
you posted as I make progress.


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
not sure about the CI tests @swill, I think the easiest way to kick Travis 
tests is the close/reopen the PR.
I'll pick it up as soon as possible. I'll rebuild and run the smoketests. 
@blueorangutan package



> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9282) VPC Inline LB plugin (VPC Public Load Balancing)

[Urvi Shah (JIRA)]

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

Urvi Shah commented on CLOUDSTACK-9282:
---

PR : https://github.com/apache/cloudstack/pull/2010

> VPC Inline LB plugin (VPC Public Load Balancing)
> 
>
> Key: CLOUDSTACK-9282
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9282
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Nick Livens
>Assignee: Nick Livens
>




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

[jira] [Commented] (CLOUDSTACK-9282) VPC Inline LB plugin (VPC Public Load Balancing)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9282:


GitHub user urvis opened a pull request:

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

VPC Inline LB - CLOUDSTACK-9282

BUG-ID: CLOUDSTACK-9282
Design-Doc: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340894

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

$ git pull https://github.com/nuagenetworks/cloudstack feature/vpc_inline_lb

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

https://github.com/apache/cloudstack/pull/2010.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 #2010


commit 5cadc414e6043eac2035ce9cf670c806bbb37ec2
Author: Urvi Shah 
Date:   2016-05-27T12:16:54Z

VPC Inline LB

BUG-ID: CLOUDSTACK-9282
Design-Doc: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340894




> VPC Inline LB plugin (VPC Public Load Balancing)
> 
>
> Key: CLOUDSTACK-9282
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9282
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Nick Livens
>Assignee: Nick Livens
>




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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
@borisstoyanov alright, this is ready for you to start testing.  Can you 
kick off CI on this as well?

I will be doing testing of this locally as well.  

This implementation is very similar to how it was implemented before my 
original change.  See: 
https://github.com/apache/cloudstack/pull/1741/files#diff-a7d6f7150cca74029f23c19b72ad0622L19

The only change from the original was that if the IP is a `source_nat` IP 
and there are already IPs associated with that dev, it will `prepend` instead 
of `append` so the source nat ip is set as the primary ip on the nic (required 
for VPN).


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9827) Storage tags stored in multiple places

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9827:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1994
  
@karuturi I added marvin tests to simulate tests performed by 
@mike-tutkowski.

This are results in our env:

[root@ussarlabcsmgt41 cloudstack]# cat /tmp//MarvinLogs//011CTF/results.txt
Test primary storage pools - XEN. Not Supported for kvm,hyperv,vmware ... 
SKIP: iscsi primary storage not supported on kvm, VMWare, Hyper-V, or LXC
Test primary storage pools - XEN, KVM, VMWare. Not Supported for hyperv ... 
=== TestName: test_01_primary_storage_nfs | Status : SUCCESS ===
ok
Test Deploy VMS using different Service Offerings with Storage Tags ... === 
TestName: test_01_deploy_vms_storage_tags | Status : SUCCESS ===
ok
Test edit Storage Tags ... === TestName: test_02_edit_primary_storage_tags 
| Status : SUCCESS ===
ok
Test Volume migration options for Storage Pools with different Storage Tags 
... SKIP: Skipping test as it is not running on simulator

--
Ran 5 tests in 295.996s

OK (SKIP=2)


@rafaelweingartner @mike-tutkowski @karuturi can you please review marvin 
tests added?


> Storage tags stored in multiple places
> --
>
> Key: CLOUDSTACK-9827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9827
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: N/A
>Reporter: Mike Tutkowski
>Assignee: Nicolas Vazquez
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> I marked this as a Blocker because it concerns me that we are not handling 
> storage tags correctly in 4.10 and, as such, VM storage might get placed in 
> locations that users don't want.
> From e-mails I sent to dev@ (most recent to oldest):
> If I add a new primary storage and give it a storage tag, the tag ends up in 
> storage_pool_details.
> If I edit an existing storage pool’s storage tags, it places them in 
> storage_pool_tags.
> **
> I believe I have found another bug (one that we should either fix or examine 
> in detail before releasing 4.10).
> It looks like we have a new table: cloud.storage_pool_tags.
> The addition of this table seems to have broken the listStorageTags API 
> command. When this command runs, it doesn’t pick up any storage tags for me 
> (and I know I have one storage tag).
> This data used to be stored in the cloud.storage_pool_details table. It’s 
> good to put it in its own table, but will our upgrade process move the 
> existing tags from storage_pool_details to storage_pool_tags?



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

[jira] [Commented] (CLOUDSTACK-9827) Storage tags stored in multiple places

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9827:


Github user nvazquez commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1994#discussion_r106724343
  
--- Diff: 
engine/schema/src/com/cloud/storage/dao/StoragePoolTagsDaoImpl.java ---
@@ -77,4 +92,71 @@ public void deleteTags(long poolId) {
 txn.commit();
 }
 
+@Override
+public List searchByIds(Long... stIds) {
+final int detailsBatchSize = getDetailsBatchSize();
+
+// query details by batches
+List uvList = new ArrayList();
+int curr_index = 0;
+
+if (stIds.length > detailsBatchSize) {
--- End diff --

Done! Thanks a lot @rafaelweingartner!


> Storage tags stored in multiple places
> --
>
> Key: CLOUDSTACK-9827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9827
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: N/A
>Reporter: Mike Tutkowski
>Assignee: Nicolas Vazquez
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> I marked this as a Blocker because it concerns me that we are not handling 
> storage tags correctly in 4.10 and, as such, VM storage might get placed in 
> locations that users don't want.
> From e-mails I sent to dev@ (most recent to oldest):
> If I add a new primary storage and give it a storage tag, the tag ends up in 
> storage_pool_details.
> If I edit an existing storage pool’s storage tags, it places them in 
> storage_pool_tags.
> **
> I believe I have found another bug (one that we should either fix or examine 
> in detail before releasing 4.10).
> It looks like we have a new table: cloud.storage_pool_tags.
> The addition of this table seems to have broken the listStorageTags API 
> command. When this command runs, it doesn’t pick up any storage tags for me 
> (and I know I have one storage tag).
> This data used to be stored in the cloud.storage_pool_details table. It’s 
> good to put it in its own table, but will our upgrade process move the 
> existing tags from storage_pool_details to storage_pool_tags?



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
Thanks @remibergsma.  I am going to use `source_nat` as it better 
represents what it is I am trying to establish and it seems to always be in the 
object where `first_i_p` does not always seem to be present (look at 
@borisstoyanov's output above for example).

@borisstoyanov I will work on getting you the new implementation today.


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user remibergsma commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
@swill FYI if you look for `first_i_p` as seen in the json on the Python 
side, then on the Java side it's called `firstIP`, as the gson lib replaces 
every capital with an underscore and then the lowercase letter.


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Closed] (CLOUDSTACK-6074) [Doc] System Implementation Guide

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6074.
--
Resolution: Fixed

> [Doc] System Implementation Guide
> -
>
> Key: CLOUDSTACK-6074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6074
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Priority: Minor
>
> Requirement from Iliyas Shirol, InMobi. System Implementation Guide which has 
> all the set of activities and tracks everything while deploying a private 
> cloud.



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

[jira] [Closed] (CLOUDSTACK-8807) Cloudstack WebUI sometimes bothers about the selected project, sometimes not

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-8807.
--
   Resolution: Invalid
Fix Version/s: (was: Future)

> Cloudstack WebUI sometimes bothers about the selected project, sometimes not
> 
>
> Key: CLOUDSTACK-8807
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8807
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.1
> Environment: cloudstack 4.5.1 with advanced networking
>Reporter: Matthias Hänni
>Priority: Minor
>  Labels: features, newbie
>
> Hello I'm pretty new on this jira board. But I found a strange behaviour in 
> Cloudstack WebUI that I would like to report:
> Logged in as root-admin
> under Home>Infrastructure>Virtual Routers
> I see all Routers when I choose Project: "default view".
> And only the project Routers when I choose one of the projects.
> But under Home>Infrastructure>ESX-Server-XY>Instances
> I always only see VM's from the selected Project. 
> There is no way to see all VM's running on a particular ESX-Host.
>  



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

[jira] [Closed] (CLOUDSTACK-9003) Make VM naming services injectable and in their own module

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-9003.
--
Resolution: Fixed

> Make VM naming services injectable and in their own module
> --
>
> Key: CLOUDSTACK-9003
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9003
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jeffrey Hair
>Priority: Minor
>
> Proposal: Make the various classes/code that give VMs and other resources 
> hostnames, hypervisor guest names, and UUIDs into their classes as injectable 
> dependencies in their own module under the core or backend module.
> This proposal originally only concerned the VirtualMachineName class and can 
> be broken down into several parts:
> * Make the VirtualMachineName class an injectable dependency instead of being 
> full of static methods.
> * Refactor the generateHostName method in UserVmManagerImpl to be backed by 
> an injectable service which generates host names.
> * Move the UUIDManagerImpl from the core module to a new module (grouped with 
> the other 2 ideally).
> Rationale:
> * VirtualMachineName is one of the few remaining classes that has static 
> methods tangled like spaghetti throughout the code. This change will put it 
> in line with the rest of the management server codebase and opens the door to 
> extensibility. Which brings us to...
> * Extensibility: The ultimate goal of this feature is to provide 3rd party 
> developers the option of changing default instance/resource naming policies. 
> Currently this is possible in a very limited fashion with the instance.name 
> global setting, but this proposal makes it much more extensible.
> By moving the naming-related services (VirtualMachineName, UUIDManager, and 
> more as added/discovered) to their own module, the module can be excluded by 
> modules.properties and different ones substituted in. Alternatively, it could 
> use the adapter model that other classes use, and the user can configure 
> which adapters are active and also provide custom ones.
> A good use case for this functionality is using a different style naming to 
> emulate other cloud providers such as AWS (i-abc123) or GCE. 



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

[jira] [Closed] (CLOUDSTACK-8806) Powered off VM's not showing up in WebUI

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-8806.
--
   Resolution: Invalid
Fix Version/s: (was: Future)

> Powered off VM's not showing up in WebUI
> 
>
> Key: CLOUDSTACK-8806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8806
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.1
> Environment: CloudStack WebUI 4.5.1 advanced networking
>Reporter: Matthias Hänni
>Priority: Minor
>  Labels: easyfix, newbie
>
> Hello I'm new on this jira board.
> But I found a strange behaviour in the Cloudstack WebUI that I like to report:
> Under Home>Infrastructure>Hosts>ESX-ServerXY>Instances
> Only running VM's are shown.
> Even if I select the filter "stopped" I don't see the stopped VM's.
> In this view (Instances on an Esx-Host) the "Filter"-Choices are pretty 
> useless:
> - "All": only showing running VM
> - "mine": I can only access this view as a root-admin
> - "running": shows the same as "all"
> - "stopped": never shows anything, because cloudstack deletes the Info about 
> on what ESX the VM is registered, directly after the VM is stopped.
> - "destroyed": same as "stopped". A destroyed VM is always stopped and in the 
> cloudstack DB not assigned to an esx Host



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

[jira] [Closed] (CLOUDSTACK-6057) Re-Organize properties related to DB HA in db.properties

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6057.
--
Resolution: Fixed

> Re-Organize properties related to DB HA in db.properties
> 
>
> Key: CLOUDSTACK-6057
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6057
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Damodar Reddy T
>Assignee: Damodar Reddy T
>Priority: Minor
> Fix For: Future
>
>
> Re organize properties related to DB HA in db.properties to group them by 
> editable and non-editable properties as there are only 3 to 4 properties are 
> editable



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

[jira] [Closed] (CLOUDSTACK-6567) IAM : Writing Integration test cases for listNetworks

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6567.
--
Resolution: Fixed

> IAM : Writing Integration test cases for listNetworks
> -
>
> Key: CLOUDSTACK-6567
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6567
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: IAM
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>
> Writing test cases for listNetworks IAM functionality.



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

[jira] [Closed] (CLOUDSTACK-6059) Restarting a VPC that has a Private Gateway fails due to a NPE, but message is not clear

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6059.
--
Resolution: Fixed

> Restarting a VPC that has a Private Gateway fails due to a NPE, but message 
> is not clear
> 
>
> Key: CLOUDSTACK-6059
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6059
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.1, 4.4.2
> Environment: Cloudstack 4.2.1-SNAPSHOT, Linux
>Reporter: Wilder Rodrigues
>Priority: Minor
>
> When trying to restart a VPC that has a Private Gateway configured, it fails 
> with a message "Failed to restart VPC". However, in the logs, we have 
> observed that there is a NullPointerException when calling 
> createPrivateNicProfileForGateway(VpcVirtualNetworkApplianceManagerImpl.java:1295).
> We know that's not possible to restart a VPC that has a Private Gateway, but 
> we are opening this issue just to have in mind that the method is currently 
> returning "null" and the message on the UI is not clear at all.
> 2014-02-07 10:53:22,639 DEBUG [db.Transaction.Transaction] 
> (Job-Executor-75:job-224729 = [ bb0b666a-ef03-4712-bc62-f3e27c82282c ]) 
> Rolling back the transaction: Time = 3 Name =  -AsyncJobManagerImp
> l$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
>  called by -Transac
> tion.rollback:897-PrivateIpDaoImpl.allocateIpAddress:85-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-VpcVirtualNetworkApplianceManagerImpl.createPrivateNicProfileForGatew
> ay:1294-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-VpcVirtualNetworkApplianceManagerImpl.createVpcRouterNetworks:1250-VpcVirtualNetworkApplianceManagerImpl.deployVpcRou
> ter:329-VpcVirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInVpc:227-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-VpcVirtualNetworkApplianceManagerImpl.deploy
> VirtualRouterInVpc:176-VpcVirtualRouterElement.implementVpc:126-VpcManagerImpl.startVpc:992
> 2014-02-07 10:53:22,642 WARN  [network.vpc.VpcManagerImpl] 
> (Job-Executor-75:job-224729 = [ bb0b666a-ef03-4712-bc62-f3e27c82282c ]) 
> Failed to start vpc [VPC [237-SBP_VPC_AJENKINS1] due to
> java.lang.NullPointerException
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createPrivateNicProfileForGateway(VpcVirtualNetworkApplianceManagerImpl.java:1295)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createVpcRouterNetworks(VpcVirtualNetworkApplianceManagerImpl.java:1250)
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.deployVpcRouter(VpcVirtualNetworkApplianceManagerImpl.java:329)
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInVpc(VpcVirtualNetworkApplianceManagerImpl.java:227)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.deployVirtualRouterInVpc(VpcVirtualNetworkApplianceManagerImpl.java:176)
> at 
> com.cloud.network.element.VpcVirtualRouterElement.implementVpc(VpcVirtualRouterElement.java:126)
> at 
> com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:992)
> at 
> com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:964)
> at 
> com.cloud.network.vpc.VpcManagerImpl.restartVpc(VpcManagerImpl.java:1304)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.vpc.RestartVPCCmd.execute(RestartVPCCmd.java:80)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> 

[jira] [Closed] (CLOUDSTACK-6484) Unable to expunge VM

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6484.
--
Resolution: Invalid

> Unable to expunge VM
> 
>
> Key: CLOUDSTACK-6484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6484
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, XenServer
>Affects Versions: 4.3.0
> Environment: ACS 4.3, XenServer 6.2 SP1, NFS primary and secondary 
> storage
>Reporter: Erik Weber
>Priority: Minor
>
> VM creation failed, and is now unable to expunge the stale vm.
> Log excerpt:
> 2014-04-23 12:37:38,632 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-17:ctx-63a3ec65) ===START===  172.30.86.24 -- GET  
> command=expungeVirtualMachine=05c7735f-43ab-4e75-b211-3791bceb77f9=json=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256658590
> 2014-04-23 12:37:38,664 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-17:ctx-63a3ec65 ctx-fc4c0a3b) submit async job-827, details: 
> AsyncJobVO {id:827, userId: 2, accountId: 2, instanceType: VirtualMachine, 
> instanceId: 80, cmd: org.apache.cloudstack.api.command.admin.vm.ExpungeVMCmd, 
> cmdInfo: 
> {"id":"05c7735f-43ab-4e75-b211-3791bceb77f9","response":"json","sessionkey":"OMJLVfWJLawkctDOi728+2sfpzI\u003d","cmdEventType":"VM.EXPUNGE","ctxUserId":"2","httpmethod":"GET","_":"1398256658590","ctxAccountId":"2","ctxStartEventId":"3505"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345049426471, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-04-23 12:37:38,667 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-6:job-827) Add job-827 into job monitoring
> 2014-04-23 12:37:38,667 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-6:job-827) Executing AsyncJobVO {id:827, userId: 2, 
> accountId: 2, instanceType: VirtualMachine, instanceId: 80, cmd: 
> org.apache.cloudstack.api.command.admin.vm.ExpungeVMCmd, cmdInfo: 
> {"id":"05c7735f-43ab-4e75-b211-3791bceb77f9","response":"json","sessionkey":"OMJLVfWJLawkctDOi728+2sfpzI\u003d","cmdEventType":"VM.EXPUNGE","ctxUserId":"2","httpmethod":"GET","_":"1398256658590","ctxAccountId":"2","ctxStartEventId":"3505"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345049426471, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-04-23 12:37:38,668 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-17:ctx-63a3ec65 ctx-fc4c0a3b) ===END===  172.30.86.24 -- GET  
> command=expungeVirtualMachine=05c7735f-43ab-4e75-b211-3791bceb77f9=json=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256658590
> 2014-04-23 12:37:38,719 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Sync job-828 execution on object 
> VmWorkJobQueue.80
> 2014-04-23 12:37:38,724 WARN  [c.c.u.d.Merovingian2] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Was unable to find lock for the key 
> vm_instance80 and thread id 2057517175
> 2014-04-23 12:37:41,720 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-19:ctx-309c7bb0) ===START===  172.30.86.24 -- GET  
> command=queryAsyncJobResult=849b6fb8-c20f-4362-8fc4-6877f36df874=json=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256661662
> 2014-04-23 12:37:41,753 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-19:ctx-309c7bb0 ctx-51354ef7) ===END===  172.30.86.24 -- GET  
> command=queryAsyncJobResult=849b6fb8-c20f-4362-8fc4-6877f36df874=json=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256661662
> 2014-04-23 12:37:41,821 DEBUG [c.c.c.CapacityManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) VM state transitted from :Expunging 
> to Expunging with event: ExpungeOperationvm's original host id: null new host 
> id: null host id before state transition: null
> 2014-04-23 12:37:41,823 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Destroying vm VM[User|i-9-80-VM]
> 2014-04-23 12:37:41,824 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Cleaning up NICS
> 2014-04-23 12:37:41,832 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-6:job-827) Unexpected exception while executing 
> org.apache.cloudstack.api.command.admin.vm.ExpungeVMCmd
> java.lang.NullPointerException
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:489)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:455)
>   at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1739)
>   at com.cloud.vm.UserVmManagerImpl.expungeVm(UserVmManagerImpl.java:3855)
>   at 

[jira] [Closed] (CLOUDSTACK-9028) GloboDNS doen´t work with "Shared Networks"

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-9028.
--
Resolution: Invalid

> GloboDNS doen´t work with "Shared Networks"
> ---
>
> Key: CLOUDSTACK-9028
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9028
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.5.2
> Environment: Cloudstack 4.5.2 with XenServer 6.5
>Reporter: Luciano Castro
>Priority: Minor
>  Labels: API, DNSAPI, GloboDNS
>
> Hi! ,
>   * Goal: Try to use GloboDNS with "Shared network".
>   * Problem: Got some errors when try to create the Network with 
> Networking Service with DNSAPI.
>   > URL Errors: 
>   -> 
> https://www.dropbox.com/s/x0w6o1pczac0r45/adding_guest_network-error.PNG?dl=0
>   -> 
> https://www.dropbox.com/s/p92p0ut5gr7t7p4/adding_guest_network.PNG?dl=0
>   
>   How to reproduce?
>   
>   * After enable GloboDNS (in "Network Service Providers"), create 
> "Network Offering" (DNS: GloboDNS), try to create a network with this service 
> offering.
>   
>   *** At original 
> spec(https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+integration+by+Globo+DNSAPI),
>  ***
>   *** it´s not clear if it is supported with "Shared Networks", but when 
> I try to add the Network, the option at the GUI is enable for me. ***
>   
>   But I receive this error:
>   
> 2015-11-03 17:58:13,787 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-3:ctx-fcc3f031) ===START===  10.225.8.161 -- GET  
> command=createNetwork=3b00a6fa-379b-4ddb-a859-267ad433ed5e=a83a593b-44a0-4825-8fda-97c2073b4594=77d61e10-100a-4bb9-ad34-1ec9d0d391ab=VLAN-DSV=VLAN-DSV=2900=domain=10.235.151.1=255.255.255.0=10.235.151.8=10.235.151.254=dsv-cloud.tpn.terra.com=json&_=1446573576495
> 2015-11-03 17:58:13,826 INFO  [c.c.a.ApiServer] (catalina-exec-3:ctx-fcc3f031 
> ctx-ff209cc4) Cannot specify CIDR when using network offering with external 
> devices!
>   
>   But I need specify a network, I´m using "Shared Networks".
>   
>   Dev team, can you check this?
>   
> thanks
> Luciano Castro



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

[jira] [Closed] (CLOUDSTACK-6033) User changing OS type from the UI returns "Only ROOT admins are allowed to modify this attribute"

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6033.
--
Resolution: Fixed

> User changing OS type from the UI returns "Only ROOT admins are allowed to 
> modify this attribute"
> -
>
> Key: CLOUDSTACK-6033
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6033
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, UI
>Affects Versions: 4.2.1
>Reporter: Francois Gaudreault
>Priority: Minor
>
> When a user upload an ISO, and tries to change the OS type afterward, the UI 
> will output an error:
> Only ROOT admins are allowed to modify this attribute.
> The parameter appears to be saved even if this error occurs. I would expect a 
> user template/ISO can be edited by the user who owns it.



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

[jira] [Closed] (CLOUDSTACK-6639) Test case : listAffinityGroups

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6639.
--
Resolution: Fixed

> Test case : listAffinityGroups
> --
>
> Key: CLOUDSTACK-6639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6639
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-6638) Test case : listVolumes

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6638.
--
Resolution: Fixed

> Test case : listVolumes
> ---
>
> Key: CLOUDSTACK-6638
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6638
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-6640) Test case : listAutoScalePolicy

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6640.
--
Resolution: Fixed

> Test case : listAutoScalePolicy
> ---
>
> Key: CLOUDSTACK-6640
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6640
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-6637) IAM : Integration test cases

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6637.
--
Resolution: Fixed

> IAM : Integration test cases
> 
>
> Key: CLOUDSTACK-6637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6637
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: IAM
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>
> Integration test cases for IAM module.



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

[jira] [Closed] (CLOUDSTACK-6641) Test case : listAutoScaleVmProfiles

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6641.
--
Resolution: Fixed

> Test case : listAutoScaleVmProfiles
> ---
>
> Key: CLOUDSTACK-6641
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6641
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-6643) Test case : listConditions

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6643.
--
Resolution: Fixed

> Test case : listConditions
> --
>
> Key: CLOUDSTACK-6643
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6643
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-6848) Test Case : listFirewallRules

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6848.
--
Resolution: Fixed

> Test Case : listFirewallRules
> -
>
> Key: CLOUDSTACK-6848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6848
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: IAM
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>
> Writing test cases for listFirewallRules IAM functionality.



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

[jira] [Closed] (CLOUDSTACK-6642) Test case : listAutoScaleVmGroups

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6642.
--
Resolution: Fixed

> Test case : listAutoScaleVmGroups
> -
>
> Key: CLOUDSTACK-6642
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6642
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-7142) Coverity Issues fixes and better error messages

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-7142.
--
   Resolution: Fixed
Fix Version/s: (was: Future)

> Coverity Issues fixes and better error messages
> ---
>
> Key: CLOUDSTACK-7142
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7142
> 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
>Reporter: Damodar Reddy T
>Assignee: Damodar Reddy T
>Priority: Minor
>




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

[jira] [Closed] (CLOUDSTACK-6849) Test Case : listAccounts

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-6849.
--
Resolution: Fixed

> Test Case : listAccounts
> 
>
> Key: CLOUDSTACK-6849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6849
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: IAM
>Reporter: Meghna Kale
>Assignee: Meghna Kale
>Priority: Minor
>
> Test cases for listAccounts for IAM functionality



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

[jira] [Closed] (CLOUDSTACK-7048) Add "usediops" parameter to StoragePool API response

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-7048.
--
Resolution: Fixed

> Add "usediops" parameter to StoragePool API response
> 
>
> Key: CLOUDSTACK-7048
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7048
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Yoshikazu Nojima
>Assignee: Yoshikazu Nojima
>Priority: Minor
>
> To monitor how many iops are allocated to volumes in total, this ticket adds 
> "usediops" parameter to StoragePool API response.



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

[jira] [Closed] (CLOUDSTACK-7379) 200MB limit setting too low for network.throttling.rate and vm.network.throttling.rate

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-7379.
--
Resolution: Invalid

> 200MB limit setting too low for network.throttling.rate and 
> vm.network.throttling.rate
> --
>
> Key: CLOUDSTACK-7379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7379
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nick Burke
>Priority: Minor
>
> Per user emailing list, ilya feels this default setting is too low and 
> requests that I make a bug report for it. 



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

[jira] [Closed] (CLOUDSTACK-7167) DATA Volume does not expunge

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-7167.
--
Resolution: Invalid

> DATA Volume does not expunge
> 
>
> Key: CLOUDSTACK-7167
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7167
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.2.1
> Environment: CentOS, XenServer 6.2
>Reporter: Aneel Dadani
>Priority: Minor
>
> When an instance is expunged, the ROOT volume is expunged, but the DATA 
> volume remains. The expunge.delay and expunge.interval is set to run every 24 
> hours. We have to manually delete the DATA volumes.



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

[jira] [Closed] (CLOUDSTACK-3012) Manual section 4.5.6.2 details what to install to have a working NFS server on RedHat but not Ubuntu

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-3012.
--
Resolution: Fixed

> Manual section 4.5.6.2 details what to install to have a working NFS server 
> on RedHat but not Ubuntu
> 
>
> Key: CLOUDSTACK-3012
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3012
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Affects Versions: 4.1.0
> Environment: Ubuntu Precise
>Reporter: Gary Richards
>Priority: Minor
>  Labels: documentation
>
> Manual section 4.5.6.2 details what to install to have a working NFS server 
> on RedHat but not Ubuntu.
> I part 1 of this section is says:
> On RHEL/CentOS systems, you'll need to install the nfs-utils package:
> $ sudo yum install nfs-utils
> I believe the following should be added:
> On Ubuntu systems, you'll need to install the nfs-kernel-server package:
> $ sudo apt-get install nfs-kernel-server



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

[jira] [Closed] (CLOUDSTACK-4232) Mail subject in Thunderbird displays =?ANSI_X3.4-1968?Q?

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-4232.
--
Resolution: Fixed

> Mail subject in Thunderbird displays =?ANSI_X3.4-1968?Q?
> 
>
> Key: CLOUDSTACK-4232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4232
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1
> Environment: CentOS 6.4+
>Reporter: France
>Priority: Minor
>
> When management server sends an email regarding an event, subject read in 
> latest Thunderbird is all mangled up. Here is an example:
> =?ANSI_X3.4-1968?Q?Unable_to_restart_v-358-VM_which?= 
> =?ANSI_X3.4-1968?Q?_was_running_on_host_name:_x1.c.i?= 
> =?ANSI_X3.4-1968?Q?CENSURED(id:3),_availability_zone:_I?= 
> =?ANSI_X3.4-1968?Q?CENSURED=3Fka_CENSURED,_pod:_CENSURED_KV2_#1?=
> Also local chars like šđžćč don't display correctly.



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

[jira] [Closed] (CLOUDSTACK-3477) resizeDataVolume doesn't return proper error message when trying to shrink volume on KVM

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-3477.
--
   Resolution: Fixed
Fix Version/s: (was: Future)

> resizeDataVolume doesn't return proper error message when trying to shrink 
> volume on KVM
> 
>
> Key: CLOUDSTACK-3477
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3477
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, KVM
>Affects Versions: 4.2.0
> Environment: Management Server: RHEL 6.3
> KVM : Rhel 6.3
>Reporter: Pavan Kumar Bandarupally
>Assignee: Kishan Kavala
>Priority: Minor
> Attachments: jessica_example1.jpg
>
>
> Shrink of QCOW2 data volumes is not supported. When user tries to shrink data 
> volume of a VM on KVM, there is no error returned by the CloudStack UI. In 
> the UI task (shrink data volume) will be completed successfully.
> The task should not be shown as successful as the operation is not supported 
> by code.



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

[jira] [Closed] (CLOUDSTACK-3896) [PrimaryStorage] deleteStoragePool is not kicking GC for the downloaded system vm templates on Primary Storage

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-3896.
--
   Resolution: Fixed
Fix Version/s: (was: Future)

> [PrimaryStorage] deleteStoragePool is not kicking GC for the downloaded 
> system vm templates on Primary Storage
> --
>
> Key: CLOUDSTACK-3896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.2.0
> Environment: commit # ca474d0e09f772cb22abf2802a308a2da5351592
>Reporter: venkata swamybabu budumuru
>Assignee: edison su
>Priority: Minor
> Attachments: logs.tgz
>
>
> Steps to reproduce:
> 1. Have the latest cloudstack setup with at least 1 advanced zone using 
> XenServer
> 2. make sure that system vm is up and running (which means the system vm is 
> downloaded to the primary storage)
> 3. Disable zone and destroy the system vas
> 4. place the primary & secondary storages in maintenance mode.
> 5. delete both primary and secondary
> # select * from storage_pool where id=12
> *** 9. row ***
>id: 12
>  name: primaryZone2
>  uuid: NULL
> pool_type: NetworkFilesystem
>  port: 2049
>data_center_id: 2
>pod_id: 2
>cluster_id: 2
>used_bytes: 1993387966464
>capacity_bytes: 5902284816384
>  host_address: 10.147.28.7
> user_info: NULL
>  path: /export/home/swamy/primary.campo.xen.1.cluster
>   created: 2013-07-29 07:19:06
>   removed: 2013-07-29 09:14:19
>   update_time: NULL
>status: Maintenance
> storage_provider_name: DefaultPrimary
> scope: CLUSTER
>hypervisor: NULL
>   managed: 0
> capacity_iops: NULL
> 6. check cloud.template_spool_ref for the above system vm template.
> Observations:
> (i) template_spool_ref still shows that system vm template as "Ready"
> (ii) storage GC didn't happen for the above template.
> mysql> select * from template_spool_ref where pool_id=12\G
> *** 1. row ***
> id: 10
>pool_id: 12
>template_id: 1
>created: 2013-07-29 07:22:12
>   last_updated: NULL
> job_id: NULL
>   download_pct: 100
> download_state: DOWNLOADED
>  error_str: NULL
> local_path: 332cedca-b187-4af8-9d0a-ac3379741211
>   install_path: 332cedca-b187-4af8-9d0a-ac3379741211
>  template_size: 0
>  marked_for_gc: 0
>  state: Ready
>   update_count: 2
>updated: 2013-07-29 07:36:24
> 1 row in set (0.00 sec)
> (iii) Storage.cleanup.interval is enabled and set to 10 in my setup.
> Attaching all the required logs along with db dump to the bug.



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

[jira] [Resolved] (CLOUDSTACK-4365) EN: Misalignment issue occurred in Events page after dragging the scroll bar down and up.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-4365.

Resolution: Fixed

> EN: Misalignment issue occurred in Events page after dragging the scroll bar 
> down and up.
> -
>
> Key: CLOUDSTACK-4365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4365
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: Environment
> Build# CloudPlatform-4.2-426 (CloudPlatform-4.2-426-rhel6.3.tar.gz) 
> Host Server: Tempa RTM
> NFS, CS-Mgr Servers: RHEL6.3
> Client & Browser: Win7-Chrome, Win7-Firefox22.0, Mac-Safari, Ubuntu-Firefox, 
> Win8-IE10
> Language: EN
>Reporter: Minying Bao
>Priority: Minor
> Attachments: Display as normal.jpg, Misalignment_Chrome.jpg, 
> Misalignment_Firefox.jpg, Misalignment_IE10.jpg, Misalignment_Safari.jpg, 
> Misalignment_Ubuntu.jpg
>
>
> Repro Steps
> Setup Basic environments with Build# CloudPlatform-4.2-283.
> Open the browser and login to Web Portal.
> Navigate the “Events” tab.
> Drag the scroll bar down and up 
> Expected Result
> The UI should display as normal.
> Actual Result
> Misalignment issue occurred in Events page after dragging the scroll bar down 
> and up.
> Browser Info.
> Win7-Chrome -> Fail
> Win8-IE10 -> Fail
> Win7-Firefox22.0 -> Fail
> Ubuntu-Firefox -> Fail
> Mac-Safari6.0 -> Fail



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

[jira] [Closed] (CLOUDSTACK-4523) Secondary Storage was offline, but Cloudstack was still attempting to use it to create a template

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-4523.
--
Resolution: Invalid

> Secondary Storage was offline, but Cloudstack was still attempting to use it 
> to create a template
> -
>
> Key: CLOUDSTACK-4523
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4523
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Template
>Affects Versions: 4.1.1
> Environment: CentOS 6.3 KVM Host with NFS Secondary Storage.
>Reporter: David Mabry
>Priority: Minor
>
> We had an issue with our Secondary Storage that caused it to become 
> unavailable.  The IP wasn't available and NFS was definitely not running.  
> When looking in the Cloudstack interface the Secondary Storage still showed 
> as enabled and showed green.  During the outage, a user attempted to create a 
> template from a VM and Cloudstack said that is was created successfully and 
> sure enough the template showed up to be used in the web interface.  Then the 
> user tried to provision a new VM from the template and Cloudstack returned an 
> error on the VM creation that is detailed in the logs below.
> Once we cleared the issue, the template was still no where to be found and 
> the user had to recreate the template from the source VM again.
> Below are what I think are relevant logs to this issue.  Please let me know 
> if you need more information.
> Template Creation
> 2013-08-27 11:06:43,775 DEBUG [agent.transport.Request] 
> (Job-Executor-148:job-1897) Seq 1-1768326350: Sending  { Cmd , MgmtId: 
> 159090354809909, via: 1, Ver: v1, Flags: 100011, 
> [{"CreatePrivateTemplateFromVolumeCommand":{"_vmName":"i-48-359-VM","_volumePath":"a8ce8492-34d7-4ec2-86c2-fed1d8077557","_userSpecifiedName":"Wk8r2
>  Gold - IIS & 
> .net4.5","_uniqueName":"41d2b232-6a60-43b4-b2d7-58e82c095f91","_templateId":317,"_accountId":48,"_primaryPool":{"id":201,"uuid":"d37a92a6-8e01-41d2-ae43-0fad35f092ad","host":"localhost","path":"/store01","port":0,"type":"CLVM"},"_secondaryStorageUrl":"nfs://172.27.15.30/nfs/cssec","primaryStoragePoolNameLabel":"d37a92a6-8e01-41d2-ae43-0fad35f092ad","wait":10800}}]
>  }
> 2013-08-27 11:15:46,557 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-8:null) Seq 1-1768326350: Processing:  { Ans: , MgmtId: 
> 159090354809909, via: 1, Ver: v1, Flags: 10, 
> [{"storage.CreatePrivateTemplateAnswer":{"_path":"/template/tmpl/48/317/41d2b232-6a60-43b4-b2d7-58e82c095f91.qcow2","_virtualSize":21474836480,"_physicalSize":1281678,"_uniqueName":"41d2b232-6a60-43b4-b2d7-58e82c095f91","_format":"QCOW2","result":true,"wait":0}}]
>  }
> 2013-08-27 11:15:46,566 DEBUG [agent.transport.Request] 
> (Job-Executor-148:job-1897) Seq 28-183400063: Sending  { Cmd , MgmtId: 
> 159090354809909, via: 28, Ver: v1, Flags: 100111, 
> [{"ComputeChecksumCommand":{"templatePath":"/template/tmpl/48/317/41d2b232-6a60-43b4-b2d7-58e82c095f91.qcow2","secUrl":"nfs://192.168.15.30/nfs/cssec","wait":0}}]
>  }
> 2013-08-27 11:36:37,287 DEBUG [cloud.user.AccountManagerImpl] 
> (catalina-exec-5:null) Access to 
> Tmpl[317-QCOW2-41d2b232-6a60-43b4-b2d7-58e82c095f91 granted to 
> Acct[31-jsmith] by DomainChecker_EnhancerByCloudStack_6e37dedb
> 2013-08-27 11:36:37,468 DEBUG [cloud.user.AccountManagerImpl] 
> (Job-Executor-149:job-1898) Access to 
> Tmpl[317-QCOW2-41d2b232-6a60-43b4-b2d7-58e82c095f91 granted to 
> Acct[31-jsmith] by DomainChecker_EnhancerByCloudStack_6e37dedb
> 2013-08-27 11:36:50,207 DEBUG [agent.transport.Request] 
> (Job-Executor-149:job-1898) Seq 3-416367865: Sending  { Cmd , MgmtId: 
> 159090354809909, via: 3, Ver: v1, Flags: 100111, 
> [{"storage.CreateCommand":{"volId":416,"pool":{"id":201,"uuid":"d37a92a6-8e01-41d2-ae43-0fad35f092ad","host":"localhost","path":"/NAzone01cluster01store01","port":0,"type":"CLVM"},"diskCharacteristics":{"size":21474836480,"tags":["prod"],"type":"ROOT","name":"ROOT-361","useLocalStorage":false,"recreatable":true,"diskOfferingId":16,"volumeId":416,"hyperType":"KVM"},"templateUrl":"nfs://192.168.15.30/nfs/cssec//template/tmpl/48/317/41d2b232-6a60-43b4-b2d7-58e82c095f91.qcow2","wait":0}}]
>  }
> ==Failed VM Deployment==
> 2013-08-27 11:39:12,475 DEBUG [agent.transport.Request] 
> (Job-Executor-149:job-1898) Seq 3-416367910: Received:  { Ans: , MgmtId: 
> 159090354809909, via: 3, Ver: v1, Flags: 110, { StopAnswer } }
> 2013-08-27 11:39:12,482 DEBUG [cloud.network.NetworkManagerImpl] 
> (Job-Executor-149:job-1898) Changing active number of nics for network id=206 
> on -1
> 2013-08-27 11:39:12,486 DEBUG [cloud.network.NetworkManagerImpl] 
> (Job-Executor-149:job-1898) 

[jira] [Closed] (CLOUDSTACK-4759) ssvm is not detected at (re)start by ms

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-4759.
--
Resolution: Resolved

> ssvm is not detected at (re)start by ms
> ---
>
> Key: CLOUDSTACK-4759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future
> Environment: dev in eclipse on windows
>Reporter: Daan Hoogland
>Priority: Minor
> Attachments: Dump20130930.sql, vmops.log
>
>
> ssvm is running and has status running in the db. The MS is started and 
> should detect the ssvm in a while. It seems not to as it keeps outputting:
> INFO  [o.a.c.s.e.DefaultEndPointSelector] (StatsCollector-3:null) No running 
> ssvm is found, so command will be sent to LocalHostEndPoint



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

[jira] [Closed] (CLOUDSTACK-4870) Naming Conventions under Marvin

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-4870.
--
Resolution: Invalid

> Naming Conventions under Marvin
> ---
>
> Key: CLOUDSTACK-4870
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4870
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Reporter: Santhosh Kumar Edukulla
>Priority: Minor
>
> Currently, there were few naming conventions which are not aligned with other 
> conventions followed.  EX: Few methods under deployDataCenters class has 
> naming conventions not aligned with all other conventions followed. 
> "createpods","createnetworks" etc. Using this bug to track these conventions 
> and fix



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

[jira] [Closed] (CLOUDSTACK-5650) attempt to update storage pool with empty tag but did not take effect

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-5650.
--
Resolution: Fixed

> attempt to update storage pool with empty tag but did not take effect 
> --
>
> Key: CLOUDSTACK-5650
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5650
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
>Affects Versions: 4.2.0
> Environment: vmware
> advanced zone
>Reporter: Ma Jinkai
>Priority: Minor
>
> in StorageManagerImpl.java line of 857:
> if (updatedDetails.size() > 0) {
> _storagePoolDao.updateDetails(id, updatedDetails);
> }
> Storage Pool has tag: SSD
> Update tag to empty, but did not take effect.



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

[jira] [Closed] (CLOUDSTACK-5642) KVM - LibvirtDomainXMLParser did not support

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-5642.
--
Resolution: Fixed

> KVM - LibvirtDomainXMLParser did not support 
> --
>
> Key: CLOUDSTACK-5642
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5642
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.0.0
>Reporter: howie yu
>Priority: Minor
>  Labels: patch
>
> n this document 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Support+in+Cloudstack
>  , CloudStack should support direct mode.
> Direct Networking
> Libvirt supports direct attachment of the guest VM's network to a physical 
> interface. To enable this mode, add the following to agent.properties:
> libvirt.vif.driver=com.cloud.hypervisor.kvm.resource.DirectVifDriver
> network.direct.source.mode=private (other values: bridge|vepa)
> network.direct.device=eth0
> But I found the following code may cause some problem, when the nic interface 
> type is direct
> If type is direct , then this nic will be ignore.
>  String type = nic.getAttribute("type");
> String mac = getAttrValue("mac", "address", nic);
> String dev = getAttrValue("target", "dev", nic);
> String model = getAttrValue("model", "type", nic);
> InterfaceDef def = new InterfaceDef();
> NodeList bandwidth = nic.getElementsByTagName("bandwidth");
> Integer networkRateKBps = 0;
> if ((bandwidth != null) && (bandwidth.getLength() != 0)) {
> Integer inbound = Integer.valueOf(getAttrValue("inbound", 
> "average", (Element)bandwidth.item(0)));
> Integer outbound = 
> Integer.valueOf(getAttrValue("outbound", "average", 
> (Element)bandwidth.item(0)));
> if (inbound == outbound)
> networkRateKBps = inbound;
> }
> if (type.equalsIgnoreCase("network")) {
> String network = getAttrValue("source", "network", nic);
> def.defPrivateNet(network, dev, mac, 
> nicModel.valueOf(model.toUpperCase()), networkRateKBps);
> } else if (type.equalsIgnoreCase("bridge")) {
> String bridge = getAttrValue("source", "bridge", nic);
> def.defBridgeNet(bridge, dev, mac, 
> nicModel.valueOf(model.toUpperCase()), networkRateKBps);
> } else if (type.equalsIgnoreCase("ethernet")) {
> String scriptPath = getAttrValue("script", "path", nic);
> def.defEthernet(dev, mac, 
> nicModel.valueOf(model.toUpperCase()), scriptPath, networkRateKBps);
> }
> interfaces.add(def);



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
@borisstoyanov could you please test with my suggestion? I think it should 
fix the duplicated nics in VR.


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Closed] (CLOUDSTACK-1036) GUI eats lots of CPU on browser side when managing larger (80-100) port forwarding rules

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-1036.
--
Resolution: Invalid

> GUI eats lots of CPU on browser side when managing larger (80-100) port 
> forwarding rules
> 
>
> Key: CLOUDSTACK-1036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1036
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Frank Breedijk
>Priority: Minor
>
> I was managin an evironment with 40 instances and 80-100 port forwarding 
> rules. Adding a rules takes ages because there seems to be a lot of client 
> side JSON parsing going on.



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

[jira] [Commented] (CLOUDSTACK-9706) Retry deleting snapshot if deleteSnapshot command failed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9706:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1867
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 471
 Hypervisor xenserver
 NetworkType Advanced
 Passed=148
 Failed=17
 Skipped=10

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


**Failed tests:**
* test_vpc_vpn.py

 * test_01_redundant_vpc_site2site_vpn Failing since 2 runs

 * test_01_vpc_site2site_vpn Failing since 2 runs

* test_snapshots.py

 * test_02_list_snapshots_with_removed_data_store Failed

 * test_02_list_snapshots_with_removed_data_store Failing since 2 runs

* test_outofbandmanagement.py

 * test_oobm_background_powerstate_sync Failed

 * test_oobm_enabledisable_across_clusterzones Failed

 * test_oobm_issue_power_cycle Failed

 * test_oobm_issue_power_off Failed

 * test_oobm_issue_power_on Failed

 * test_oobm_issue_power_reset Failed

 * test_oobm_issue_power_soft Failed

 * test_oobm_issue_power_status Failed

 * test_oobm_multiple_mgmt_server_ownership Failed

 * test_oobm_zchange_password Failed

* test_volumes.py

 * ContextSuite context=TestCreateVolume>:setup Failing since 13 runs

* test_internal_lb.py

 * ContextSuite context=TestInternalLb>:setup Failed

* test_routers_network_ops.py

 * test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false Failing since 
2 runs


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_01_primary_storage_iscsi
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
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_vpc_router_nics.py
test_over_provisioning.py
test_global_settings.py
test_guest_vlan_range.py
test_scale_vm.py
test_service_offerings.py
test_router_dhcphosts.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_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_password_server.py
test_dynamicroles.py
test_vm_life_cycle.py
test_disk_offerings.py


> Retry deleting snapshot if deleteSnapshot command failed 
> -
>
> Key: CLOUDSTACK-9706
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9706
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Currently when we delete snapshot then we mark it to be in destroyed state 
> first and then we go to delete it on storage if it can be deleted. If the 
> deletion of snapshot fails then we never retry to delete it which fills up 
> storage.



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

[jira] [Closed] (CLOUDSTACK-1306) Better Error message when trying to deploy Vm by passing static Ipv4 addresses that are assigned to another VM/IP4 address is outside the iprange.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-1306.
--
   Resolution: Later
Fix Version/s: (was: Future)

> Better Error message when trying to deploy Vm by passing static Ipv4 
> addresses that are assigned to another VM/IP4 address is outside the iprange. 
> ---
>
> Key: CLOUDSTACK-1306
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1306
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.1.0, 4.2.0
> Environment: Latest from Network Refactor branch,
>Reporter: Sangeetha Hariharan
>Assignee: Saksham Srivastava
>Priority: Minor
>
> Better Error message when handling Better Error message when trying to deploy 
> Vm by passing static Ipv4 addresses that are assigned to another VM/IP4 
> address is outside the iprange.
> Steps to reproduce the problem:
> Scenario1:
> "Pre Req:
> 1.Create Dual Stack Shared Network by passing ipv6 params and ipv4 params
> Steps:
> Deploy Vm by passing a static Ipaddress that is already assigned to a 
> different VM using ipaddress and networkIds."
> Scenario2:
> Pre Req:
> 1.Create Dual Stack Shared Network by passing ipv6 params and ipv4 params
> Steps:
> Deploy Vm by passing a static Ipaddress that is not in the range of the 
> specified network using  ipaddress and networkIds
> Scenario3:
> Pre Req:
> 1.Create Dual Stack Shared Network by passing ipv6 params and ipv4 params
> Steps:
> Deploy Vm by passing a static Ipaddress that belongs to different network 
> that is other than network using  ipaddress and networkIds
> In all above cases ,user is presented with "Insufficient address capacity" as 
> the error message.
> Expected Behavior:
> User should be presented with more meaningful messages that will allow him to 
> take corrective actions.



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

[jira] [Resolved] (CLOUDSTACK-696) Networks with same name & VLAN are allowed in the same Zone

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-696.
---
Resolution: Fixed

> Networks with same name & VLAN are allowed in the same Zone
> ---
>
> Key: CLOUDSTACK-696
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-696
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: pre-4.0.0
> Environment: CloudStack version: 3.0.5.20120904142539
>Reporter: Vladimir Ostrovsky
>Priority: Minor
> Attachments: Two networks with identical names.png
>
>
> CloudStack permits to create several networks of the same name and the same 
> VLAD ID in the same Advanced zone, if their IP subnets are different.
> This makes it hard to distinguish between networks while adding a new VM 
> instance. Also it caused two DHCP servers (Virtual Routers) to be placed in 
> the same VLAN.



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

[jira] [Closed] (CLOUDSTACK-994) Feature Request: Support VmWare Storage Pool

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-994.
-
Resolution: Fixed

> Feature Request: Support VmWare Storage Pool
> 
>
> Key: CLOUDSTACK-994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-994
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.1.0, 4.2.0
> Environment: CS 4.1
>Reporter: ilya musayev
>Priority: Minor
>
> VmWare 4.x has the support for storage pool- where as, you bundled your 
> LUNs/datastores into 1 storage pool and vmware will take of proper allocation.
> If possible - it would be a great addition to CloudStack.



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

[jira] [Reopened] (CLOUDSTACK-692) The CleanupSnapshotBackup process on SSVM deletes snapshots that are still in the process of being copied to secondary storage.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner reopened CLOUDSTACK-692:
---

> The CleanupSnapshotBackup process on SSVM deletes snapshots that are still in 
> the process of being copied to secondary storage.
> ---
>
> Key: CLOUDSTACK-692
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-692
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Reporter: Joris van Lieshout
>Priority: Minor
>
> Hi there,
> I think we ran into a bug due to a concurrence of circumstances regarding 
> snapshotting and the cleanup of snapshots.
> The CleanupSnapshotBackup process on the SSVM deletes vhd files that are not 
> known in the database but when, especially long running snapshot, are being 
> copied to secondary storeage there is a gap between the start and finish of 
> the VDI-copy, where the uuid of the destination vhd is not registered in the 
> database. If the CleanupSnapshotBackup deletes the destinaion vhd during this 
> window it results in hanging sparse_dd process on the XenServer hypervisor 
> pointing to a tapdisk2 process with no file behind it.
> ===Secondary storage vm (2 hour time difference due to time zone). second to 
> last line you see the vhd being deleted.
> 2013-09-04 03:14:45,721 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Request:Seq 261-1870805144:  { Cmd , MgmtId: 345052370018, via: 261, Ver: v1, 
> Flags: 100011, 
> [{"CleanupSnapshotBackupCommand":{"secondaryStoragePoolURL":"nfs://mccpnas7.storage.mccp.mcinfra.net/volumes/pool0/MCCP-SHARED-1-1","dcId":1,"accountId":45,"volumeId":5863,"validBackupUUIDs":["1a56760b-d1c0-4620-8cf7-271951500d70","b6157bc9-085b-4ed6-95c2-4341f31c64bf","1ff967e3-3606-4112-9155-b1145b2ef576","12fbe4e3-1fdd-4c35-a961-0fce07cff584","278e9915-4f94-40c8-bef4-9c6bc82d4653","6fba1dd7-4736-47b3-9eed-148304c0e192","b9d8c9d8-6445-463b-b4e1-ab3b3f3a67a2","40ba5d72-c69a-46c2-973b-0570c1cabeac","774f2b0e-cdaf-4594-a9f9-4f872dcaad6e","8269f50b-6bec-427c-8186-540df6a75dbf","7b0c6e75-40cf-4dd7-826a-09b39f3da7b5","df7eac9c-137a-4655-9d21-d781916351f1","11ec2db1-a2fc-4221-ae1a-c1ab2bd59509","dfc348e1-af50-4d77-b4a0-6e86fc954e1c","98f64c0f-7498-4c70-8b70-beaefd723b45","c42f9dd5-079d-4b77-86dc-c19b7fbed817"],"wait":0}}]
>  }
> 2013-09-04 03:14:45,722 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Processing command: com.cloud.agent.api.CleanupSnapshotBackupCommand
> 2013-09-04 03:14:45,723 DEBUG [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) Executing: mount 
> 2013-09-04 03:14:45,732 DEBUG [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) Execution is successful.
> 2013-09-04 03:14:45,772 WARN  [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) snapshot 8ca9fea4-8a98-4cc3-bba7-cc1dcf32bb24.vhd 
> is not recorded in DB, remove it
> 2013-09-04 03:14:45,772 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Seq 261-1870805144:  { Ans: , MgmtId: 345052370018, via: 261, Ver: v1, Flags: 
> 10, [{"Answer":{"result":true,"wait":0}}] }
>  management-server.log. here you see the snapshot being created, the 
> copyToSecStorage process starting, eventually timing out due to the hanging 
> vdi-copy, failing on retrying because vdi in use (although not existing any 
> more the vdi is still know on xen), retrying some more on another HV and 
> eventuall giving up because it tries to create a duplicate SR.
> 2013-09-04 04:27:10,931 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-69:job-95137) Executing 
> com.cloud.api.commands.CreateSnapshotCmd for job-95137
> 2013-09-04 04:27:10,971 DEBUG [agent.transport.Request] 
> (Job-Executor-69:job-95137) Seq 91-780303147: Sending  { Cmd , MgmtId: 
> 345052370017, via: 91, Ver: v1, Flags: 100011, 
> [{"ManageSnapshotCommand":{"_commandSwitch":"-c","_volumePath":"9cb7af90-ca88-4b34-aa6f-bc21c3d4a3aa","_pool":{"id":208,"uuid":"b290385b-466d-3243-a939-3d242164e034","host":"mccpnas3-4-vip1.mccp.mcinfra.net","path":"/volumes/pool0/MCCP-S-SBP1-1_MCCP-XEN-1","port":2049,"type":"NetworkFilesystem"},"_snapshotName":"vlstws3_ROOT-2736_20130904022710","_snapshotId":71889,"_vmName":"i-45-2736-VM","wait":0}}]
>  }
> 2013-09-04 04:27:10,971 DEBUG [agent.transport.Request] 
> (Job-Executor-69:job-95137) Seq 91-780303147: Executing:  { Cmd , MgmtId: 
> 345052370017, via: 91, Ver: v1, Flags: 100011, 
> 

[jira] [Closed] (CLOUDSTACK-692) The CleanupSnapshotBackup process on SSVM deletes snapshots that are still in the process of being copied to secondary storage.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-692.
-
Resolution: Done

> The CleanupSnapshotBackup process on SSVM deletes snapshots that are still in 
> the process of being copied to secondary storage.
> ---
>
> Key: CLOUDSTACK-692
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-692
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Reporter: Joris van Lieshout
>Priority: Minor
>
> Hi there,
> I think we ran into a bug due to a concurrence of circumstances regarding 
> snapshotting and the cleanup of snapshots.
> The CleanupSnapshotBackup process on the SSVM deletes vhd files that are not 
> known in the database but when, especially long running snapshot, are being 
> copied to secondary storeage there is a gap between the start and finish of 
> the VDI-copy, where the uuid of the destination vhd is not registered in the 
> database. If the CleanupSnapshotBackup deletes the destinaion vhd during this 
> window it results in hanging sparse_dd process on the XenServer hypervisor 
> pointing to a tapdisk2 process with no file behind it.
> ===Secondary storage vm (2 hour time difference due to time zone). second to 
> last line you see the vhd being deleted.
> 2013-09-04 03:14:45,721 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Request:Seq 261-1870805144:  { Cmd , MgmtId: 345052370018, via: 261, Ver: v1, 
> Flags: 100011, 
> [{"CleanupSnapshotBackupCommand":{"secondaryStoragePoolURL":"nfs://mccpnas7.storage.mccp.mcinfra.net/volumes/pool0/MCCP-SHARED-1-1","dcId":1,"accountId":45,"volumeId":5863,"validBackupUUIDs":["1a56760b-d1c0-4620-8cf7-271951500d70","b6157bc9-085b-4ed6-95c2-4341f31c64bf","1ff967e3-3606-4112-9155-b1145b2ef576","12fbe4e3-1fdd-4c35-a961-0fce07cff584","278e9915-4f94-40c8-bef4-9c6bc82d4653","6fba1dd7-4736-47b3-9eed-148304c0e192","b9d8c9d8-6445-463b-b4e1-ab3b3f3a67a2","40ba5d72-c69a-46c2-973b-0570c1cabeac","774f2b0e-cdaf-4594-a9f9-4f872dcaad6e","8269f50b-6bec-427c-8186-540df6a75dbf","7b0c6e75-40cf-4dd7-826a-09b39f3da7b5","df7eac9c-137a-4655-9d21-d781916351f1","11ec2db1-a2fc-4221-ae1a-c1ab2bd59509","dfc348e1-af50-4d77-b4a0-6e86fc954e1c","98f64c0f-7498-4c70-8b70-beaefd723b45","c42f9dd5-079d-4b77-86dc-c19b7fbed817"],"wait":0}}]
>  }
> 2013-09-04 03:14:45,722 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Processing command: com.cloud.agent.api.CleanupSnapshotBackupCommand
> 2013-09-04 03:14:45,723 DEBUG [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) Executing: mount 
> 2013-09-04 03:14:45,732 DEBUG [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) Execution is successful.
> 2013-09-04 03:14:45,772 WARN  [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) snapshot 8ca9fea4-8a98-4cc3-bba7-cc1dcf32bb24.vhd 
> is not recorded in DB, remove it
> 2013-09-04 03:14:45,772 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Seq 261-1870805144:  { Ans: , MgmtId: 345052370018, via: 261, Ver: v1, Flags: 
> 10, [{"Answer":{"result":true,"wait":0}}] }
>  management-server.log. here you see the snapshot being created, the 
> copyToSecStorage process starting, eventually timing out due to the hanging 
> vdi-copy, failing on retrying because vdi in use (although not existing any 
> more the vdi is still know on xen), retrying some more on another HV and 
> eventuall giving up because it tries to create a duplicate SR.
> 2013-09-04 04:27:10,931 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-69:job-95137) Executing 
> com.cloud.api.commands.CreateSnapshotCmd for job-95137
> 2013-09-04 04:27:10,971 DEBUG [agent.transport.Request] 
> (Job-Executor-69:job-95137) Seq 91-780303147: Sending  { Cmd , MgmtId: 
> 345052370017, via: 91, Ver: v1, Flags: 100011, 
> [{"ManageSnapshotCommand":{"_commandSwitch":"-c","_volumePath":"9cb7af90-ca88-4b34-aa6f-bc21c3d4a3aa","_pool":{"id":208,"uuid":"b290385b-466d-3243-a939-3d242164e034","host":"mccpnas3-4-vip1.mccp.mcinfra.net","path":"/volumes/pool0/MCCP-S-SBP1-1_MCCP-XEN-1","port":2049,"type":"NetworkFilesystem"},"_snapshotName":"vlstws3_ROOT-2736_20130904022710","_snapshotId":71889,"_vmName":"i-45-2736-VM","wait":0}}]
>  }
> 2013-09-04 04:27:10,971 DEBUG [agent.transport.Request] 
> (Job-Executor-69:job-95137) Seq 91-780303147: Executing:  { Cmd , MgmtId: 
> 345052370017, via: 91, Ver: v1, Flags: 100011, 
> 

[jira] [Closed] (CLOUDSTACK-692) The CleanupSnapshotBackup process on SSVM deletes snapshots that are still in the process of being copied to secondary storage.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-692.
-
Resolution: Unresolved

> The CleanupSnapshotBackup process on SSVM deletes snapshots that are still in 
> the process of being copied to secondary storage.
> ---
>
> Key: CLOUDSTACK-692
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-692
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Reporter: Joris van Lieshout
>Priority: Minor
>
> Hi there,
> I think we ran into a bug due to a concurrence of circumstances regarding 
> snapshotting and the cleanup of snapshots.
> The CleanupSnapshotBackup process on the SSVM deletes vhd files that are not 
> known in the database but when, especially long running snapshot, are being 
> copied to secondary storeage there is a gap between the start and finish of 
> the VDI-copy, where the uuid of the destination vhd is not registered in the 
> database. If the CleanupSnapshotBackup deletes the destinaion vhd during this 
> window it results in hanging sparse_dd process on the XenServer hypervisor 
> pointing to a tapdisk2 process with no file behind it.
> ===Secondary storage vm (2 hour time difference due to time zone). second to 
> last line you see the vhd being deleted.
> 2013-09-04 03:14:45,721 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Request:Seq 261-1870805144:  { Cmd , MgmtId: 345052370018, via: 261, Ver: v1, 
> Flags: 100011, 
> [{"CleanupSnapshotBackupCommand":{"secondaryStoragePoolURL":"nfs://mccpnas7.storage.mccp.mcinfra.net/volumes/pool0/MCCP-SHARED-1-1","dcId":1,"accountId":45,"volumeId":5863,"validBackupUUIDs":["1a56760b-d1c0-4620-8cf7-271951500d70","b6157bc9-085b-4ed6-95c2-4341f31c64bf","1ff967e3-3606-4112-9155-b1145b2ef576","12fbe4e3-1fdd-4c35-a961-0fce07cff584","278e9915-4f94-40c8-bef4-9c6bc82d4653","6fba1dd7-4736-47b3-9eed-148304c0e192","b9d8c9d8-6445-463b-b4e1-ab3b3f3a67a2","40ba5d72-c69a-46c2-973b-0570c1cabeac","774f2b0e-cdaf-4594-a9f9-4f872dcaad6e","8269f50b-6bec-427c-8186-540df6a75dbf","7b0c6e75-40cf-4dd7-826a-09b39f3da7b5","df7eac9c-137a-4655-9d21-d781916351f1","11ec2db1-a2fc-4221-ae1a-c1ab2bd59509","dfc348e1-af50-4d77-b4a0-6e86fc954e1c","98f64c0f-7498-4c70-8b70-beaefd723b45","c42f9dd5-079d-4b77-86dc-c19b7fbed817"],"wait":0}}]
>  }
> 2013-09-04 03:14:45,722 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Processing command: com.cloud.agent.api.CleanupSnapshotBackupCommand
> 2013-09-04 03:14:45,723 DEBUG [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) Executing: mount 
> 2013-09-04 03:14:45,732 DEBUG [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) Execution is successful.
> 2013-09-04 03:14:45,772 WARN  [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:) snapshot 8ca9fea4-8a98-4cc3-bba7-cc1dcf32bb24.vhd 
> is not recorded in DB, remove it
> 2013-09-04 03:14:45,772 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:) 
> Seq 261-1870805144:  { Ans: , MgmtId: 345052370018, via: 261, Ver: v1, Flags: 
> 10, [{"Answer":{"result":true,"wait":0}}] }
>  management-server.log. here you see the snapshot being created, the 
> copyToSecStorage process starting, eventually timing out due to the hanging 
> vdi-copy, failing on retrying because vdi in use (although not existing any 
> more the vdi is still know on xen), retrying some more on another HV and 
> eventuall giving up because it tries to create a duplicate SR.
> 2013-09-04 04:27:10,931 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-69:job-95137) Executing 
> com.cloud.api.commands.CreateSnapshotCmd for job-95137
> 2013-09-04 04:27:10,971 DEBUG [agent.transport.Request] 
> (Job-Executor-69:job-95137) Seq 91-780303147: Sending  { Cmd , MgmtId: 
> 345052370017, via: 91, Ver: v1, Flags: 100011, 
> [{"ManageSnapshotCommand":{"_commandSwitch":"-c","_volumePath":"9cb7af90-ca88-4b34-aa6f-bc21c3d4a3aa","_pool":{"id":208,"uuid":"b290385b-466d-3243-a939-3d242164e034","host":"mccpnas3-4-vip1.mccp.mcinfra.net","path":"/volumes/pool0/MCCP-S-SBP1-1_MCCP-XEN-1","port":2049,"type":"NetworkFilesystem"},"_snapshotName":"vlstws3_ROOT-2736_20130904022710","_snapshotId":71889,"_vmName":"i-45-2736-VM","wait":0}}]
>  }
> 2013-09-04 04:27:10,971 DEBUG [agent.transport.Request] 
> (Job-Executor-69:job-95137) Seq 91-780303147: Executing:  { Cmd , MgmtId: 
> 345052370017, via: 91, Ver: v1, Flags: 100011, 
> 

[jira] [Resolved] (CLOUDSTACK-626) guest_os table does not have latest distro

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-626.
---
Resolution: Fixed

> guest_os table does not have latest distro
> --
>
> Key: CLOUDSTACK-626
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-626
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.1.0, 4.2.0
>Reporter: sebastien goasguen
>Priority: Minor
>
> test/conf/templates.sql creates the guest_os table.
> It does not contain latest distro.
> For instance Ubuntu 12.04 is not there. 
> How do we keep this list up to date and retire old distro ?



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

[jira] [Resolved] (CLOUDSTACK-506) [UI] Unable to execute API command liststoragepools

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-506.
---
Resolution: Fixed

> [UI] Unable to execute API command liststoragepools
> ---
>
> Key: CLOUDSTACK-506
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-506
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.0.0
> Environment: CentOS 6.3 
> kernel-2.6.32-279.14.1.el6.x86_64
> lvm2-2.02.95-10.el6_3.2.x86_64
> lvm2-cluster-2.02.95-10.el6_3.2.x86_64
> lvm2-libs-2.02.95-10.el6_3.2.x86_64
> qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
> libvirt-0.9.10-21.el6_3.5.x86_64
> libvirt-client-0.9.10-21.el6_3.5.x86_64
>Reporter: Richard Shevel
>Priority: Minor
> Attachments: error.png
>
>
> When i try add the primary storage (CLVM). I get an error , such as 
> Unable to execute API command liststoragepools due to invalid value. Obhect 
> storage_pool(uuid: undefined) does not exist.  And there is no information 
> about the newly added primary storage.
> But if i reload the page, the primary storage displayed normally.
> I attached screenshot  



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

[jira] [Resolved] (CLOUDSTACK-561) createNetwork can block for long periods causing clients to time out when called at certain times

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-561.
---
Resolution: Fixed

> createNetwork can block for long periods causing clients to time out when 
> called at certain times
> -
>
> Key: CLOUDSTACK-561
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-561
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.0.0
> Environment: KVM or Xen (maybe all environments)
>Reporter: Marcus Sorensen
>Priority: Minor
>
> createNetwork can block for minutes if called when VPC router is being 
> created (maybe non-vpc router too?), whether it's the first time or if VPC 
> router is deleted.  If I call createNetwork any time after the new VPC router 
> is running it's fine, wether the router is stopped, starting, or running 
> state. If I destroy the router then createNetwork also still works instantly, 
> but when router is recreating and in 'starting' state, createNetwork blocks 
> until this is done. Since it's a sync call this causes trouble for us, and 
> we've worked around it in our client by never calling createNetwork if the 
> VPC router is not 'running', but since createNetwork is sync we should really 
> either fix the block or return 'try again later' if this state is found.



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

[jira] [Resolved] (CLOUDSTACK-486) Clicking UI notifications for System VM or Virtual Router opens Instances page

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-486.
---
Resolution: Fixed

> Clicking UI notifications for System VM or Virtual Router opens Instances page
> --
>
> Key: CLOUDSTACK-486
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-486
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.0.0
>Reporter: Kirk Kosinski
>Priority: Minor
>
> If you click a notification in the UI for a System VM or Virtual Router, 
> instead of opening the relevant System VMs or Virtual Routers page, the 
> Instances page is opened. This is not useful since System VMs and Virtual 
> Routers do not show up on the Instances page. The relevant page should be 
> opened instead.
> To reproduce:
> 1. Log on to the UI.
> 2. Navigate to Infrastructure > System VMs or Virtual Routers.
> 3. Perform an action on one of them. For example, stop a System VM.
> 4. Wait for a notification to be generated. 
> 5. Open the notifications list and click on the notification. For the example 
> in step 3, click "Stop System VM".
> 6. Notice that the Instances page is opened.



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

[jira] [Resolved] (CLOUDSTACK-582) Cannot perform password reset for Windows instances on VMWare

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-582.
---
Resolution: Fixed

> Cannot perform password reset for Windows instances on VMWare
> -
>
> Key: CLOUDSTACK-582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-582
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, Network Devices, VMware
>Affects Versions: pre-4.0.0
> Environment: CentOS6 2.6.32-279.14.1.el6.x86_64
> ESXi 5.1
>Reporter: Bill Rich
>Priority: Minor
>
> When I attempt password reset on a Windows instance on ESXi, the job fails 
> because the management server is attempting to connect to the routing vm on 
> the link local ip address which is not used for VMWare system VMs. Below are 
> the relevant log entries from the management log.
> 2012-12-04 12:35:37,651 DEBUG [agent.transport.Request] 
> (Job-Executor-81:job-268) Seq 2-1745947325: Executing:  { Cmd , MgmtId: 
> 161332719936, via: 2, Ver: v1, Flags: 100101, 
> [{"routing.SavePasswordCommand":{"password":"nI9eufdes","vmIpAddress":"198.23.64.87","vmName":"78764853-99a4-40a4-b299-43748f0546b8","accessDetails":{"zone.network.type":"Basic","router.ip":"0.0.0.0","router.name":"r-6-VM"},"wait":0}}]
>  }
> 2012-12-04 12:35:37,651 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-306:null) Seq 2-1745947325: Executing request
> 2012-12-04 12:35:37,652 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-306:10.54.227.25) Executing resource SavePasswordCommand. 
> vmName: 78764853-99a4-40a4-b299-43748f0546b8, vmIp: 198.23.64.87, password: 
> n
> 2012-12-04 12:35:37,652 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-306:10.54.227.25) Use router's private IP for SSH control. IP : 
> 0.0.0.0
> 2012-12-04 12:35:37,652 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-306:10.54.227.25) Run command on domain router 0.0.0.0, 
> /root/savepassword.sh  -v 198.23.64.87 -p n
> 2012-12-04 12:35:37,652 ERROR [vmware.resource.VmwareResource] 
> (DirectAgent-306:10.54.227.25) SavePasswordCommand failed due to Exception: 
> java.io.IOException
> Message: There was a problem while connecting to 0.0.0.0:3922
> java.io.IOException: There was a problem while connecting to 0.0.0.0:3922
>   at com.trilead.ssh2.Connection.connect(Connection.java:791)
>   at 
> com.cloud.hypervisor.vmware.resource.SshHelper.sshExecute(SshHelper.java:127)
>   at 
> com.cloud.hypervisor.vmware.resource.SshHelper.sshExecute(SshHelper.java:32)
>   at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1780)
>   at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:339)
>   at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:187)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>   at java.lang.Thread.run(Thread.java:679)
> Caused by: java.net.ConnectException: Connection refused
>   at java.net.PlainSocketImpl.socketConnect(Native Method)
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:191)
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
>   at java.net.Socket.connect(Socket.java:546)
>   at 
> com.trilead.ssh2.transport.TransportManager.establishConnection(TransportManager.java:341)
>   at 
> com.trilead.ssh2.transport.TransportManager.initialize(TransportManager.java:449)
>   at com.trilead.ssh2.Connection.connect(Connection.java:731)
> ...
> 2012-12-04 12:35:37,654 DEBUG [cloud.vm.UserVmManagerImpl] 
> (Job-Executor-81:job-268) Failed to reset password for the virutal machine; 
> no need to reboot the vm
> 2012-12-04 12:35:37,657 ERROR [cloud.api.ApiDispatcher] 
> (Job-Executor-81:job-268) Exception while executing ResetVMPasswordCmd:
> 

[jira] [Closed] (CLOUDSTACK-438) Custom DNS entries

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-438.
-
Resolution: Fixed

> Custom DNS entries
> --
>
> Key: CLOUDSTACK-438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-438
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Reporter: Andreas Fuchs
>Assignee: Murali Reddy
>Priority: Minor
>
> A possibility to add custom DNS entries to the automgically generated would 
> be great.
> Also LB services should get an automatically generated entry for the LB 
> service name.
> We understand that this can be done on the "upstream" DNS but as this often 
> is not a multinant DNS it would be really cool if each tenant can add DNS 
> entries to his account or project.



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

[jira] [Closed] (CLOUDSTACK-458) xen:snapshots:Storage gc fail to clean the failed snapshot images from secondarystorage

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-458.
-
   Resolution: Fixed
Fix Version/s: (was: Future)

> xen:snapshots:Storage gc fail to clean the failed snapshot images from 
> secondarystorage
> ---
>
> Key: CLOUDSTACK-458
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-458
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.0.0
>Reporter: deepti dohare
>Assignee: edison su
>Priority: Minor
>
> After storage cleanup still see the snapshot image oin the secondary storage 
> snapshot folder for the failure snapshots 
> In this case : next hourly snapshot was successful but previous snapshot was 
> stuck in backingupstate 
> Steps: 
> *** 
> 1.Deploy a VM and set concurrent.snapshots.threshold.per host to 2 
> 2.Once its successful,schedule the recurring snapshots hourly on the root 
> volume and also perform snapshot on other instance volumes 
> 3.configure the storage.cleanup.interval to 150 and restart the 
> cloud-management service while hourly snapshot on root volume is in progress 
> 4.check the secondary storage snapshot folder 
> 5. after few hours,delete all the created snapshots from Cloudstack and check 
> the storage cleanup thread cleansup all the snapshots form the snapshot 
> folder or not. 
> Actual result: 
> step4:snapshots job failed and secondary storage has copied image file and 
> database shows snapshot job status as "Backing UP" 
> next hourly snapshot was successful. 
> Step5: 
> It cleans all the successful hourly snapshot images except the failed 
> snapshot image files 
> Expected result: 
> ** 
> Storage GC should clean all image files exists in the snapshot folder when we 
> delete the all the snapshots from Cloud stack. 
> also when previous hourly snapshot stuck in backing up state ,the next hourly 
> snapshot is successful,Cloudstack should intelligent enough to update the 
> status of failure jobs properly. 



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

[jira] [Closed] (CLOUDSTACK-429) Agent rebalancing is broken

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-429.
-
Resolution: Fixed

> Agent rebalancing is broken
> ---
>
> Key: CLOUDSTACK-429
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-429
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, Management Server
>Affects Versions: pre-4.0.0
> Environment: KVM, Cloudstack 3.0.2
>Reporter: Roland Kool
>Priority: Minor
>
> After setting agent.lb.enabled to true and restarting my management servers, 
> the agent rebalancing gets stuck after trying to rebalance the first 16 
> machines.
> The error from the management log is:
> 2012-07-05 15:09:43,643 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentTaskPool-6:null) Rebalancing host id=9
> 2012-07-05 15:09:43,646 WARN [agent.manager.ClusteredAgentManagerImpl] 
> (AgentTaskPool-6:null) Unable to rebalance host id=9
> java.lang.ClassCastException: com.cloud.agent.manager.ClusteredAgentAttache 
> cannot be cast to com.cloud.agent.manager.ClusteredDirectAgentAttache
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.startRebalance(ClusteredAgentManagerImpl.java:1014)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.rebalanceHost(ClusteredAgentManagerImpl.java:905)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$RebalanceTask.run(ClusteredAgentManagerImpl.java:1070)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)



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

[jira] [Resolved] (CLOUDSTACK-371) When naming physical networks in the zone wizard, special characters like () break the wizard

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-371.
---
Resolution: Fixed

> When naming physical networks in the zone wizard, special characters like () 
> break the wizard
> -
>
> Key: CLOUDSTACK-371
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-371
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.0.0
> Environment: Tested with ACS build 733 on Centos 6,3 in 
> Chrome/Firefox/IE
>Reporter: kelcey damage
>Priority: Minor
>
> When naming physical networks in the zone wizard, special characters like () 
> break the wizard.
> This will cause further pages in the wizard to render blank. Also attempting 
> to go back and fix the name will cause traffic tokens to get frozen and 
> corrupt, as well as fail to re-draw correctly.



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

[jira] [Closed] (CLOUDSTACK-245) VPC ACLs are not stored and programmed consistently

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-245.
-
   Resolution: Unresolved
 Assignee: (was: Kishan Kavala)
Fix Version/s: (was: Future)

> VPC ACLs are not stored and programmed consistently
> ---
>
> Key: CLOUDSTACK-245
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-245
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: pre-4.0.0
>Reporter: David Noland
>Priority: Minor
>
> If user specifies 1.2.3.4/24 as the CIDR for an ACL the firewall rule is 
> being programmed as 1.2.3.0/24. Both CIDRs are correct, but it's inconsistent 
> to store one thing in the database and program the firewall using another 
> rule. 



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

[jira] [Closed] (CLOUDSTACK-272) Delete failure message for network with a VM is not informative

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner closed CLOUDSTACK-272.
-
   Resolution: Fixed
Fix Version/s: (was: Future)

> Delete failure message for network with a VM is not informative
> ---
>
> Key: CLOUDSTACK-272
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-272
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: pre-4.0.0
>Reporter: David Noland
>Priority: Minor
>
> The following delete network API call is failing because there is a VM 
> running in the network:
> http://localhost:8080/client/api?command=deleteNetwork=ba5a58e8-a803-4ab1-9b1e-5389e03e2d58=json=VEubeThTbte%2FufpplNGM6NYHWlQ%3D&_=1349483483336
> The popup states: "Failed to delete network", which is coming from the JSON 
> response:
> { "queryasyncjobresultresponse" : 
> {"accountid":"d0236100-db1a-4262-939b-d5a235e87d35","userid":"9cffba2c-54c9-4fde-8b5d-7e62c01eb9ee","cmd":"com.cloud.api.commands.DeleteNetworkCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"Failed
>  to delete 
> network"},"created":"2012-10-06T00:25:43+","jobid":"f3ee91a6-c4ca-48fb-bff5-8d2f5eee7a9d"}
>  }
> This gives the user too little information on why the network deletion 
> failed. The error message should state that the network could not be deleted 
> because there are VM(s) still running in the network.



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

[jira] [Resolved] (CLOUDSTACK-9533) gateway of public IP is not handled correctly when parsing the cmd_line.json to create ips.json databag

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-9533.

Resolution: Fixed

> gateway of public IP is not handled correctly when parsing the cmd_line.json 
> to create ips.json databag
> ---
>
> Key: CLOUDSTACK-9533
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9533
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> gateway of public IP is not handled correctly when parsing the cmd_line.json 
> to create ips.json databag
> In systemvm/patches/debian/config/opt/cloud/bin/merge.py
> processCLItem following piece of code sets the local gateway as public 
> interface/ip gateway, as there is no check on the network type.
>if('localgw' in self.qFile.data['cmd_line']):
>  dp['gateway'] = self.qFile.data['cmd_line']['localgw']
> for public network type, it should be read from cmd_line.gateway



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

[jira] [Resolved] (CLOUDSTACK-8976) Sorting of security groups

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-8976.

   Resolution: Fixed
Fix Version/s: (was: Future)

> Sorting of security groups
> --
>
> Key: CLOUDSTACK-8976
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8976
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.2
>Reporter: CS User
>Priority: Minor
>
> Within the instance creation wizard, when using a basic zone with a large 
> number of security groups, it can be difficult for the user to select the 
> required group when presented with a long list. 
> Currently the list not ordered. It would be better if the groups were sorted 
> alphabetically. 



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

[jira] [Resolved] (CLOUDSTACK-7405) ec2 metadata service requires trailing / for listing items

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-7405.

Resolution: Fixed

> ec2 metadata service requires trailing / for listing items
> --
>
> Key: CLOUDSTACK-7405
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7405
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Reporter: Scott Moser
>Priority: Minor
>
> This came to me through bug reports to cloud-init:
>  https://bugs.launchpad.net/cloud-init/+bug/1356855
> and
>  https://bugs.launchpad.net/cloud-init/+bug/1311107
> Apparently, the EC2 metadata service that cloudstack provides returns a 404 
> for "dictionary" entries that do not have a trailing /.
> Example (as reported to me, i have no first hand experience).
> $ wget http://169.254.169.254/latest/meta-data ;
> 404
> $ wget http://169.254.169.254/latest/meta-data/
> $ cat index.html ; echo
> ami-id
> ami-launch-index
> ami-manifest-path
> block-device-mapping/
> hostname
> instance-action
> instance-id
> instance-type
> local-hostname
> local-ipv4
> mac
> metrics/
> network/
> placement/
> profile
> public-hostname
> public-ipv4
> public-keys/
> reservation-id
> security-groups
> services/
>   



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

[jira] [Resolved] (CLOUDSTACK-7633) Most init scripts provide an invalid name for LSB header "Provides"

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-7633.

Resolution: Fixed

> Most init scripts provide an invalid name for LSB header "Provides"
> ---
>
> Key: CLOUDSTACK-7633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Affects Versions: 4.2.0, 4.3.0, 4.4.0, Future
>Reporter: Vincent Bernat
>Priority: Minor
>
> Many init scripts have an LSB "Provides" header like this:
> {code}
> # Provides:  cloud agent
> {code}
> This means that this script provides "cloud" and "agent". This needs to be 
> fixed to say "cloud-agent" instead.



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

[jira] [Resolved] (CLOUDSTACK-3054) modify cloud-set-guest-sshkey.in initscript to handle SELinux configuration

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-3054.

Resolution: Fixed

> modify cloud-set-guest-sshkey.in initscript to handle SELinux configuration
> ---
>
> Key: CLOUDSTACK-3054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3054
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: CentOS 6.4 VM
>Reporter: Ian Service
>Priority: Minor
>
> https://reviews.apache.org/r/11934/



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

[jira] [Resolved] (CLOUDSTACK-535) Virtual Router DNS is restricted to UDP only

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-535.
---
Resolution: Fixed

> Virtual Router DNS is restricted to UDP only
> 
>
> Key: CLOUDSTACK-535
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-535
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.0.0
>Reporter: Tamas Monos
>Priority: Minor
>
> Issue:
> When a new router VM is generated and started the initial firewall rules 
> allow only port 53 on UDP. Router VMs should allow port 53 on TCP is well due 
> to longer resolutions can switch to TCP for example cPanel. The cPanel 
> installer will not run if it cannot resolve over TCP.
> Workaround:
> Login to the router VM and execute:
> iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT
> Resolution:
> I'm not sure where the initial firewall rules are coming from (maybe systemVM 
> ISO?) but there this new rule should be added.



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

[jira] [Resolved] (CLOUDSTACK-698) Modify build to generate the LICENSE and NOTICE files

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-698.
---
   Resolution: Fixed
Fix Version/s: (was: Future)

> Modify build to generate the LICENSE and NOTICE files
> -
>
> Key: CLOUDSTACK-698
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-698
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Chip Childers
>Assignee: Chip Childers
>Priority: Minor
>
> We need to modify the build to generate the LICENSE and NOTICE files, using 
> the latest changes from the Apache Whisker project.
> We also need to ensure that the manually completed change to resolve 
> CLOUDSTACK-697 is included in the 4.1.0 fix.



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

[jira] [Resolved] (CLOUDSTACK-9598) wrong defaut gateway in guest VM with nics in isolated and a shared network

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-9598.

Resolution: Fixed

> wrong defaut gateway in guest VM with nics in isolated and a shared network
> ---
>
> Key: CLOUDSTACK-9598
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9598
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.1.0
>
>
> When a guest instance is created with nic's in a isolated network and a 
> shared network (with just DHCP and DNS), with isolated network as default 
> network, DHCP lease on shared network from the shared network VR has wrong 
> gateway. gateway is pointed to the virtual router IP. 
> /etc/cloudstack/dhcpentry.json in shared network VR will have default gateway 
> set to 0.0.0.0
> root@r-11-VM:~# cat /etc/cloudstack/dhcpentry.json
> {
> "10.6.9.165": {
> "default_entry": false,
> "default_gateway": "0.0.0.0",
> "dns_adresses": "10.1.1.1",
> "host_name": "VM-fce34d73-dc99-4559-b077-64711509907a",
> "ipv4_adress": "10.6.9.165",
> "ipv6_duid": "00:03:00:01:06:5a:da:00:00:6a",
> "mac_address": "06:5a:da:00:00:6a",
> "type": "dhcpentry"
> },
> "id": "dhcpentry"
> DhcpCommand network element command sent from the management server is like 
> below with "defaultRouter":"0.0.0.0"
> 2016-11-15 19:15:29,319 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-25:ctx-a9aca0bb job-69/job-70 ctx-82c3fd7e) 
> (logid:6ca37cdb) Seq 2-4650811040190170578: Sending  { Cmd , MgmtId: 
> 7150818625286, via: 2(trl-202-k-cs49-mreddy-kvm2), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.routing.DhcpEntryCommand":{"vmMac":"06:5a:da:00:00:6a","vmIpAddress":"10.6.9.165","vmName":"VM-fce34d73-dc99-4559-b077-64711509907a","defaultRouter":"0.0.0.0","defaultDns":"10.1.1.1","duid":"00:03:00:01:06:5a:da:00:00:6a","isDefault":false,"executeInSequence":false,"accessDetails":{"zone.network.type":"Advanced","router.guest.ip":"10.6.9.164","router.ip":"169.254.2.18","router.name":"r-11-VM"},"wait":0}}]
>  }
> NIC details in the DB for the nic in the shared network has correct gateway.
> Gateway is set to 0.0.0.0, for every non-default nic [1]
> In case where shared network is non default network, then guest VM will end 
> up treating VR in the shared network as gateway instead of actual shared 
> network gateway.
> [1] 
> https://github.com/apache/cloudstack/blob/4.9/server/src/com/cloud/network/router/CommandSetupHelper.java#L224



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

[jira] [Resolved] (CLOUDSTACK-9540) createPrivateGateway create private network does not create proper VLAN network on XenServer

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-9540.

Resolution: Fixed

> createPrivateGateway create private network does not create proper VLAN 
> network on XenServer
> 
>
> Key: CLOUDSTACK-9540
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9540
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
>  While running the smoke tests in test_privategw_acl.py its observed, that 
> due to bug in the test suite (CLOUDSTACK-9511), same VLAN ends being used 
> across four test cases. createPrivateGateway API which creates a VLAN network 
> on the XenServer, skips creating the network when it exists on the XenServer 
> hosts. But PIF never gets attached to  the bridge, hence traffic from private 
> gateway never leaves the host.
> Private gateway tests consistently failed in smoke tests on the XenServer, as 
> you can see in https://github.com/apache/cloudstack/pull/1692



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

[jira] [Resolved] (CLOUDSTACK-9635) fix test_privategw_acl.py

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-9635.

Resolution: Fixed

> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Resolved] (CLOUDSTACK-350) Storage stats in admin dashboard are not pragmatic

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-350.
---
Resolution: Fixed

> Storage stats in admin dashboard are not pragmatic
> --
>
> Key: CLOUDSTACK-350
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-350
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: David Nalley
>Priority: Minor
> Attachments: snapshot7.png
>
>
> UI reports storage seemingly at the byte level, with numbers like this: 
> 105689374720
> Why aren't there units, and if you must use really low level units like 
> bytes, at least add commas to make it a bit more easily parseable. That said 
> bytes is a really non-practical unit of measure for a cloud - MB, or even GB 
> - and in some cases TB would be far more useful. 
> I'll attach a screenshot



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

[jira] [Resolved] (CLOUDSTACK-212) Switch java package structure from com.cloud to org.apache

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-212.
---
Resolution: Fixed

> Switch java package structure from com.cloud to org.apache
> --
>
> Key: CLOUDSTACK-212
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-212
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: pre-4.0.0
>Reporter: Chip Childers
>Assignee: Dharmesh Kakadia
>Priority: Minor
> Fix For: Future
>
>
> Since the project has moved over to ASF, I'd like to suggest that we move 
> from com.cloud to org.apache for the java package structure of our modules.
> If there is agreement, we can take this up after 4.0 is out the door.



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

[jira] [Resolved] (CLOUDSTACK-9509) KVM Hosts connect with no storage

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-9509.

Resolution: Fixed

> KVM Hosts connect with no storage
> -
>
> Key: CLOUDSTACK-9509
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Critical
> Fix For: 4.8.1, 4.10.0.0, 4.9.1.0
>
>
> KVM hosts on shared storage failure was accepted by mgmt server with the
> host state as Up, even though there was no primary/shared storage available 
> on it. They fail the ModifyStoragePoolCommand, but the management server 
> continues on with adding SSH keys and marking them as up.



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

[jira] [Resolved] (CLOUDSTACK-9634) fix marvin test test_router_dhcp_opts failure

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner resolved CLOUDSTACK-9634.

Resolution: Fixed

> fix marvin test test_router_dhcp_opts failure
> -
>
> Key: CLOUDSTACK-9634
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9634
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> test_router_dhcp_opts has been failing on the smoke tests on 4.8 ,4.9, 4.10. 
> This is new test added as part of fix for "CLOUDSTACK-9598: wrong defaut 
> gateway for the nic in non-default network"
> Marvin VirtualMachine object's nic attribute, does not store nics in any 
> particular order. test made the assumption the  nic[0] is default nic of the 
> virtual machine which may not necessarily true all the time
> nic objects 'isdefault' attribute can be used to verify if the nic is default 
> nic.



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

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


Github user DaanHoogland commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1582#discussion_r106675353
  
--- Diff: 
api/src/org/apache/cloudstack/api/response/AutoScaleVmProfileResponse.java ---
@@ -75,6 +75,7 @@
 @Parameter(name = ApiConstants.CS_URL,
type = CommandType.STRING,
description = "the API URL including port of the CloudStack 
Management Server example: http://server.cloud.com:8080/client/api?;)
+// leaving cloud.com reference above as it serves only as an example
--- End diff --

ok, in that perspect you have a point absolutely. The sentence would need 
to be rephrased, then. It now spells "example: http://...;!
Ive been going through the, code reviewing every occurrence of 
cloud.com, back in june!!! just before leaving the project to do some paid 
work ;) (hope my boss is alright with this remark)


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



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

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


Github user DaanHoogland commented on the issue:

https://github.com/apache/cloudstack/pull/1582
  
@karuturi I rebased on latest master, is anything else expected?


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



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

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


Github user rafaelweingartner commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1582#discussion_r106670299
  
--- Diff: 
api/src/org/apache/cloudstack/api/response/AutoScaleVmProfileResponse.java ---
@@ -75,6 +75,7 @@
 @Parameter(name = ApiConstants.CS_URL,
type = CommandType.STRING,
description = "the API URL including port of the CloudStack 
Management Server example: http://server.cloud.com:8080/client/api?;)
+// leaving cloud.com reference above as it serves only as an example
--- End diff --

I agree that it is out of the scope. I just wanted to ask about the idea of 
starting using notations instead of real URLs as examples.

To tell you the truth I have already seen so many time people not thinking 
while seeing examples like this and using a copy/paste working mode that I try 
to avoid it sometimes, just to force people to change the parameters.

It is nothing that you need to change, I just so it, and I wanted to check 
your opinion ;)


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



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

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


Github user DaanHoogland commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1582#discussion_r106667548
  
--- Diff: 
api/src/org/apache/cloudstack/api/response/AutoScaleVmProfileResponse.java ---
@@ -75,6 +75,7 @@
 @Parameter(name = ApiConstants.CS_URL,
type = CommandType.STRING,
description = "the API URL including port of the CloudStack 
Management Server example: http://server.cloud.com:8080/client/api?;)
+// leaving cloud.com reference above as it serves only as an example
--- End diff --

I don't see you point Rafael. it would no longer be an example bu a semi 
formal definition.

Also I think it is out of scope to be frank


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



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

[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9811:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2003
  
Hi @swill, could you please let us know when do you expect to address the 
changes you have mentioned, so I could schedule the testing accordingly. Thanks.


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



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

[jira] [Commented] (CLOUDSTACK-9827) Storage tags stored in multiple places

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9827:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1994
  
Hi @karuturi, I've been working on marvin tests, I hope posting them today


> Storage tags stored in multiple places
> --
>
> Key: CLOUDSTACK-9827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9827
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: N/A
>Reporter: Mike Tutkowski
>Assignee: Nicolas Vazquez
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> I marked this as a Blocker because it concerns me that we are not handling 
> storage tags correctly in 4.10 and, as such, VM storage might get placed in 
> locations that users don't want.
> From e-mails I sent to dev@ (most recent to oldest):
> If I add a new primary storage and give it a storage tag, the tag ends up in 
> storage_pool_details.
> If I edit an existing storage pool’s storage tags, it places them in 
> storage_pool_tags.
> **
> I believe I have found another bug (one that we should either fix or examine 
> in detail before releasing 4.10).
> It looks like we have a new table: cloud.storage_pool_tags.
> The addition of this table seems to have broken the listStorageTags API 
> command. When this command runs, it doesn’t pick up any storage tags for me 
> (and I know I have one storage tag).
> This data used to be stored in the cloud.storage_pool_details table. It’s 
> good to put it in its own table, but will our upgrade process move the 
> existing tags from storage_pool_details to storage_pool_tags?



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

[jira] [Commented] (CLOUDSTACK-9706) Retry deleting snapshot if deleteSnapshot command failed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9706:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1867
  
@koushik-das Failing tests doesn't seems to be related to this patch. 
Rebased against latest master to trigger the build.


> Retry deleting snapshot if deleteSnapshot command failed 
> -
>
> Key: CLOUDSTACK-9706
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9706
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Currently when we delete snapshot then we mark it to be in destroyed state 
> first and then we go to delete it on storage if it can be deleted. If the 
> deletion of snapshot fails then we never retry to delete it which fills up 
> storage.



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

[jira] [Commented] (CLOUDSTACK-9696) Fail to deploy VM on dedicating clusters and hosts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9696:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1853
  
@koushik-das Made the changes as per review comments.


> Fail to deploy VM on dedicating clusters and hosts
> --
>
> Key: CLOUDSTACK-9696
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9696
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> IN the below scenario:
> cluster C1 is having 2 hosts, H1 and H2. 
> Root domain is having 2 sub domain, D1 and D2
> C1 is dedicated to Root and H1 and H2 are dedicated to D1 and D2 respectively
> D1 and D2 has users U1 and U2 respectively
> Login into U1 and deploy the VM
> router and VM deployment failed with the error: 
> com.cloud.exception.InsufficientServerCapacityException: Unable to create a 
> deployment



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

[jira] [Commented] (CLOUDSTACK-9696) Fail to deploy VM on dedicating clusters and hosts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9696:


Github user anshul1886 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1853#discussion_r106632802
  
--- Diff: server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java ---
@@ -584,105 +583,64 @@ private void 
checkForNonDedicatedResources(VirtualMachineProfile vmProfile, Data
 isExplicit = true;
 }
 
-List allPodsInDc = _podDao.listAllPods(dc.getId());
-List allDedicatedPods = _dedicatedDao.listAllPods();
-allPodsInDc.retainAll(allDedicatedPods);
-
-List allClustersInDc = 
_clusterDao.listAllCusters(dc.getId());
-List allDedicatedClusters = _dedicatedDao.listAllClusters();
-allClustersInDc.retainAll(allDedicatedClusters);
-
-List allHostsInDc = _hostDao.listAllHosts(dc.getId());
-List allDedicatedHosts = _dedicatedDao.listAllHosts();
-allHostsInDc.retainAll(allDedicatedHosts);
-
-//Only when the type is instance VM and not explicitly dedicated.
-if (vm.getType() == VirtualMachine.Type.User && !isExplicit) {
-//add explicitly dedicated resources in avoidList
-
-avoids.addPodList(allPodsInDc);
-avoids.addClusterList(allClustersInDc);
-avoids.addHostList(allHostsInDc);
-}
-
-//Handle the Virtual Router Case
-//No need to check the isExplicit. As both the cases are handled.
-if (vm.getType() == VirtualMachine.Type.DomainRouter) {
-long vmAccountId = vm.getAccountId();
-long vmDomainId = vm.getDomainId();
-
-//Lists all explicitly dedicated resources from vm account ID 
or domain ID.
-List allPodsFromDedicatedID = new ArrayList();
-List allClustersFromDedicatedID = new ArrayList();
-List allHostsFromDedicatedID = new ArrayList();
-
-//Whether the dedicated resources belong to Domain or not. If 
not, it may belongs to Account or no dedication.
-List domainGroupMappings = 
_affinityGroupDomainMapDao.listByDomain(vmDomainId);
-
-//For temporary storage and indexing.
-List tempStorage;
-
-if (domainGroupMappings == null || 
domainGroupMappings.isEmpty()) {
-//The dedicated resource belongs to VM Account ID.
-
-tempStorage = _dedicatedDao.searchDedicatedPods(null, 
vmDomainId, vmAccountId, null).first();
-
-for(DedicatedResourceVO vo : tempStorage) {
-allPodsFromDedicatedID.add(vo.getPodId());
-}
-
-tempStorage.clear();
-tempStorage = _dedicatedDao.searchDedicatedClusters(null, 
vmDomainId, vmAccountId, null).first();
+if ((vm.getType() == VirtualMachine.Type.User && !isExplicit) || 
vm.getType() == VirtualMachine.Type.DomainRouter) {
+List allPodsInDc = _podDao.listAllPods(dc.getId());
+List allDedicatedPods = _dedicatedDao.listAllPods();
+allPodsInDc.retainAll(allDedicatedPods);
 
-for(DedicatedResourceVO vo : tempStorage) {
-allClustersFromDedicatedID.add(vo.getClusterId());
-}
+List allClustersInDc = 
_clusterDao.listAllCusters(dc.getId());
+List allDedicatedClusters = 
_dedicatedDao.listAllClusters();
+allClustersInDc.retainAll(allDedicatedClusters);
 
-tempStorage.clear();
-tempStorage = _dedicatedDao.searchDedicatedHosts(null, 
vmDomainId, vmAccountId, null).first();
+List allHostsInDc = _hostDao.listAllHosts(dc.getId());
+List allDedicatedHosts = _dedicatedDao.listAllHosts();
+allHostsInDc.retainAll(allDedicatedHosts);
 
-for(DedicatedResourceVO vo : tempStorage) {
-allHostsFromDedicatedID.add(vo.getHostId());
-}
+//Only when the type is instance VM and not explicitly 
dedicated.
+if (vm.getType() == VirtualMachine.Type.User && !isExplicit) {
+//add explicitly dedicated resources in avoidList
 
-//Remove the dedicated ones from main list
-allPodsInDc.removeAll(allPodsFromDedicatedID);
-allClustersInDc.removeAll(allClustersFromDedicatedID);
-allHostsInDc.removeAll(allHostsFromDedicatedID);
+

[jira] [Commented] (CLOUDSTACK-9696) Fail to deploy VM on dedicating clusters and hosts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9696:


Github user anshul1886 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1853#discussion_r106632584
  
--- Diff: server/src/com/cloud/dc/dao/DedicatedResourceDaoImpl.java ---
@@ -312,6 +317,65 @@ public DedicatedResourceVO findByHostId(Long hostId) {
 }
 
 @Override
+public List listAvailableResources(Long 
accountId, Long... domains) {
--- End diff --

@koushik-das Made the changes using SearchBuilder class.


> Fail to deploy VM on dedicating clusters and hosts
> --
>
> Key: CLOUDSTACK-9696
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9696
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> IN the below scenario:
> cluster C1 is having 2 hosts, H1 and H2. 
> Root domain is having 2 sub domain, D1 and D2
> C1 is dedicated to Root and H1 and H2 are dedicated to D1 and D2 respectively
> D1 and D2 has users U1 and U2 respectively
> Login into U1 and deploy the VM
> router and VM deployment failed with the error: 
> com.cloud.exception.InsufficientServerCapacityException: Unable to create a 
> deployment



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

[jira] [Commented] (CLOUDSTACK-9630) Cannot use listNics API as advertised

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9630:


Github user sudhansu7 commented on the issue:

https://github.com/apache/cloudstack/pull/1797
  
@pdion891 removed broadcasturi from api response. Also added marvin test .


> Cannot use listNics API as advertised
> -
>
> Key: CLOUDSTACK-9630
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9630
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sudhansu Sahu
>
> listNics API for a VM, "type" was not returned within API response. 
> EXPECTED BEHAVIOR
> ==
> The listNics API response return type of NIC (type), as specified in 
> https://cloudstack.apache.org/api/apidocs-4.8/user/listNics.html
>  
> ACTUAL BEHAVIOR
> ==
> The listNics API response does not return type of NIC.
> (local)  > list nics virtualmachineid=a69edaf5-8f21-41ff-8c05-263dc4bd5354 
> count = 1
> nic:
> id = 211e0d46-6b94-4425-99f7-e8e9efea2472
> deviceid = 0
> gateway = 10.1.1.1
> ipaddress = 10.1.1.45
> isdefault = True
> macaddress = 02:00:06:f6:00:01
> netmask = 255.255.255.0
> networkid = c08fddf1-fd77-4810-a062-ea9d03c5c7e6
> virtualmachineid = a69edaf5-8f21-41ff-8c05-263dc4bd5354
>  
>  



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

[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8672:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1859
  
@rajesh-battala I won't accept this PR, sorry to share this but the number 
of commits are simply outrageous.

From my experience RM-ing for 4.3, 4.5, 4.9 -- the git history is pretty 
messed-up and it becomes far too difficult to track changes, backport/up-port 
commits/fixes/feature. There have been big PR/features that have been accepted 
and merged with very few overall squashed commits.


> NCC Integration with CloudStack
> ---
>
> Key: CLOUDSTACK-8672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.6.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: Future
>
>




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

[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8672:


Github user rajesh-battala commented on the issue:

https://github.com/apache/cloudstack/pull/1859
  
Current commits are in the order of some milestones.
As @nitin-maharan told if we squash them into one commit we loose
contributions of induviduals.


On Thu, Mar 16, 2017 at 7:09 PM, Rohit Yadav 
wrote:

> @nitin-maharana  it becomes easier to
> triage changes when changes are confined to a limited number of commits
> (ideally one per PR), please squash the commits based on the author (if 
not
> to a single commit) if you don't agree. Ideally, you can also group/squash
> commits based on the component/framework/architecture.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



-- 
Thanks
Rajesh Battala



> NCC Integration with CloudStack
> ---
>
> Key: CLOUDSTACK-8672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.6.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: Future
>
>




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

[jira] [Commented] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9369:


GitHub user karuturi opened a pull request:

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

CLOUDSTACK-9369 Fixed Ldap regression

Ldap auto creation of accounts is broken due to the security fix for
CLOUDSTACK-9369.
There was an explicit check to not allow login incase the
user doesnt exist.  removed the same.

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

$ git pull https://github.com/Accelerite/cloudstack CLOUDSTACK-9369

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

https://github.com/apache/cloudstack/pull/2009.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 #2009


commit e2efebadaa9d7e7ec7be3f9638f48c7b97394f5e
Author: Rajani Karuturi 
Date:   2017-02-09T18:43:13Z

Bug-ID:CLOUDSTACK-9369 Fixed Ldap regression

Ldap auto creation of accounts is broken due to the security fix for
CLOUDSTACK-9369.
There was an explicit check to not allow login incase the
user doesnt exist.  removed the same.




> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rajani Karuturi
>Priority: Critical
>  Labels: login, loginmodule, saml
> Attachments: 
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password



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

[jira] [Commented] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9369:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/2009
  
@rhtyd Can you review the fix?


> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rajani Karuturi
>Priority: Critical
>  Labels: login, loginmodule, saml
> Attachments: 
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password



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

[jira] [Reopened] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation

[Rajani Karuturi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi reopened CLOUDSTACK-9369:
-
  Assignee: Rajani Karuturi  (was: Rohit Yadav)

> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rajani Karuturi
>Priority: Critical
>  Labels: login, loginmodule, saml
> Attachments: 
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password



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

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9408:


Github user DaanHoogland commented on the issue:

https://github.com/apache/cloudstack/pull/1582
  
sorry @karuturi should I update? This is really not on my radar that much 
anymore. I will look at it this afternoon.


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



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

[jira] [Commented] (CLOUDSTACK-9742) Simultaneous snapshots for detached volume

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9742:


Github user mrunalinikankariya commented on the issue:

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

[ConcurrentSnapshots.docx](https://github.com/apache/cloudstack/files/849895/ConcurrentSnapshots.docx)
 
Attached file contains screenshot of the database quesry and the concurrent 
snapshot created using manual testing as well as marvin script


> Simultaneous snapshots for detached volume
> --
>
> Key: CLOUDSTACK-9742
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9742
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: mrunalini
>
> A detached volume on any hypervisor (Xen, Vmware, KVM) fails to create one of 
> the snapshots if it there are two scheduled snapshots at the same time for 
> the same volume. One of that goes to Allocated state. any combination of 
> weekly,daily and hourly simultaneous snapshot creation on a detached volume 
> results one of the snapshots in Allocated state forever which can not be 
> deleted



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

[jira] [Commented] (CLOUDSTACK-9706) Retry deleting snapshot if deleteSnapshot command failed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9706:


Github user anshul1886 closed the pull request at:

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


> Retry deleting snapshot if deleteSnapshot command failed 
> -
>
> Key: CLOUDSTACK-9706
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9706
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Currently when we delete snapshot then we mark it to be in destroyed state 
> first and then we go to delete it on storage if it can be deleted. If the 
> deletion of snapshot fails then we never retry to delete it which fills up 
> storage.



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

[jira] [Commented] (CLOUDSTACK-9706) Retry deleting snapshot if deleteSnapshot command failed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9706:


GitHub user anshul1886 reopened a pull request:

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

CLOUDSTACK-9706: Added snapshots cleanup in start and storage GC thre…

…ad if they are failed to cleanup during DeleteSnapshot command

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

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

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

https://github.com/apache/cloudstack/pull/1867.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 #1867


commit e9245d3ac1a888505e9d2c1e05841791e29c51ec
Author: Anshul Gangwar 
Date:   2016-05-09T07:15:31Z

CLOUDSTACK-9706: Added snapshots cleanup in start and storage GC thread if 
they are failed to cleanup during DeleteSnapshot command




> Retry deleting snapshot if deleteSnapshot command failed 
> -
>
> Key: CLOUDSTACK-9706
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9706
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Currently when we delete snapshot then we mark it to be in destroyed state 
> first and then we go to delete it on storage if it can be deleted. If the 
> deletion of snapshot fails then we never retry to delete it which fills up 
> storage.



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