[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-8958:


Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1357#issuecomment-200251321
  
@DaanHoogland 
Like kishan said we need to look at the failed tests and if needed check 
the reason for failure. Logs can be obtained using the link and the build 
number provided in the report.

Note that some the tests are flaky as in they pass intermittently mostly 
because of hardcoded values or because the test expects that some things like a 
particular vlan or some resource will always be available.


> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain 
> ips are dedicated to Account for now, so other customers and projects in the 
> same domain will use the system ip. this is not what we need.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9318) test_privategw_acl is failing intermittently.

2016-03-23 Thread Bharat Kumar (JIRA) 
Bharat Kumar created CLOUDSTACK-9318:


 Summary: test_privategw_acl is failing intermittently.
 Key: CLOUDSTACK-9318
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9318
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.9.0
Reporter: Bharat Kumar
Priority: Critical
 Fix For: 4.9.0


The test test_privategw_acl.py is failing intermittently. This because it tries 
to use a vlan which is already in use. Need to add a check to see if a vlan is 
already in use or read the need vlan from the test_data.py file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9142) Migrate VM changes xmlDesc in an unsafe way

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9142:


Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1348#issuecomment-200300953
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 122
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=13
 Skipped=4

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


**Failed tests:**

**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_deploy_vgpu_enabled_vm
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData

integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
integration.smoke.test_over_provisioning.TestUpdateOverProvision
integration.smoke.test_global_settings.TestUpdateConfigWithScope
integration.smoke.test_scale_vm.TestScaleVm
integration.smoke.test_service_offerings.TestCreateServiceOffering
integration.smoke.test_loadbalance.TestLoadBalance
integration.smoke.test_routers.TestRouterServices
integration.smoke.test_reset_vm_on_reboot.TestResetVmOnReboot
integration.smoke.test_snapshots.TestSnapshotRootDisk

integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
integration.smoke.test_network.TestDeleteAccount
integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork
integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
integration.smoke.test_multipleips_per_nic.TestDeployVM
integration.smoke.test_regions.TestRegions
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
integration.smoke.test_network_acl.TestNetworkACL
integration.smoke.test_pvlan.TestPVLAN
integration.smoke.test_volumes.TestCreateVolume
integration.smoke.test_ssvm.TestSSVMs
integration.smoke.test_nic.TestNic
integration.smoke.test_deploy_vm_root_resize.TestDeployVM
integration.smoke.test_resource_detail.TestResourceDetail
integration.smoke.test_secondary_storage.TestSecStorageServices
integration.smoke.test_vm_life_cycle.TestDeployVM
integration.smoke.test_disk_offerings.TestCreateDiskOffering


> Migrate VM changes xmlDesc in an unsafe way
> ---
>
> Key: CLOUDSTACK-9142
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9142
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server
>Affects Versions: 4.6.0, 4.7.0
>Reporter: David Amorim Faria
>Assignee: Daan Hoogland
>Priority: Critical
>
> This issue appears with commit 
> https://github.com/apache/cloudstack/commit/a709f34ff93579981afbd4df0f4334b61ada29a8
> where xmlDesc has some content replaced: {code}
> xmlDesc = 
> dm.getXMLDesc(xmlFlag).replace(libvirtComputingResource.getPrivateIp(), 
> command.getDestinationIp());
> {code}
> This line from LibvirtComputingResource.java was refactored into 
> LibvirtMigrateCommandWrapper.java in commit 
> https://github.com/apache/cloudstack/commit/28e55462f15bdd8699e97b668c4ffc01735a533d
> Example, node1 is 10.0.0.1, node2 is 10.0.0.2, rbd mon_host is 10.0.0.13.
> VM is running on kvm node1 and this happened when migrating a VM from node1 
> to node2, where the kvm nodes and the RBD mon nodes (mon_host) use IP 
> addresses in the same range, and the mon_host has an ip address that 
> partially matches the ip address (string) of the first kvm node.
> In the process list one can see that the mon_host changes from 10.0.0.13 to 
> 10.0.0.23 in the destination host, blocking the migration after a timeout due 
> to primary storage not being available.
> {code}
> root 25206  1.8  0.0 440184 17188 ?Sl   13:33   0:00 
> /usr/libexec/qemu-kvm -name r-74-VM -S -machine 
> pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu 
> host,+rdtscp,+pdpe1gb,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
>  -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
> 1a32b655-0acf-424b-8722-9e7f507a3070 -smbios type=1,manufacturer=Apache 
> Software Foundation,product=CloudStack KVM 
> Hypervisor,uuid=1a32b655-0acf-424b-8722-9e7f507a3070 -no-user-config 
> -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-r-74-VM/monitor.sock,server,

[jira] [Created] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

2016-03-23 Thread Aaron Brady (JIRA) 
Aaron Brady created CLOUDSTACK-9319:
---

 Summary: Timeout is not passed to virtual router operations 
consistently
 Key: CLOUDSTACK-9319
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.8.0
 Environment: KVM + Ceph cloud, Ubuntu hosts.
Reporter: Aaron Brady
Priority: Trivial


The timeout parameter is not passed down to `applyConfigToVR` inside 
`VirtualRoutingResource` in all cases.

This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
is larger), but because it's not passed to the first invocation, the default 
(120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.

In a recent upgrade of our Virtual Routers, the timeout was being hit and 
increasing `router.aggregation.command.each.timeout` had no effect. I built a 
custom 4.8 agent with the timeout increased to allow the upgrade to continue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9319:


GitHub user insom opened a pull request:

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

CLOUDSTACK-9319: Use timeout when applying config to virtual router

From the [JIRA 
issue](https://issues.apache.org/jira/browse/CLOUDSTACK-9319):

> The timeout parameter is not passed down to `applyConfigToVR` inside 
`VirtualRoutingResource` in all cases.
> 
> This timeout is worked out as 3 seconds per command or 120 seconds 
(whichever is larger), but because it's not passed to the first invocation, the 
default (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> 
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
increasing `router.aggregation.command.each.timeout` had no effect. I built a 
custom 4.8 agent with the timeout increased to allow the upgrade to continue.


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

$ git pull https://github.com/insom/cloudstack CLOUDSTACK-9319

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

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


commit 9f353b4672c0f875b7f64b4d1fadd458ff9abad3
Author: Aaron Brady 
Date:   2016-03-23T12:15:24Z

Use timeout when applying config to virtual router




> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9320) Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last Internal Load Balancer rule is removed for the corresponding source IP address

2016-03-23 Thread Mani Prashanth Varma Manthena (JIRA) 
Mani Prashanth Varma Manthena created CLOUDSTACK-9320:
-

 Summary: Nuage VSP SDN Plugin: InternalLBVM is not getting 
destroyed when the last Internal Load Balancer rule is removed for the 
corresponding source IP address
 Key: CLOUDSTACK-9320
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9320
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller, Third-Party Bugs
Reporter: Mani Prashanth Varma Manthena
Priority: Critical
 Fix For: 4.9.0


Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last 
Internal Load Balancer rule is removed for the corresponding source IP address.

This not the expected behavior with feature Internal LB, refer the following 
documentation of the feature Internal LB:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers

InternalLBVM is only getting destroyed when we restart the Internal LB network 
with cleanup (or) delete the network.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9320) Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last Internal Load Balancer rule is removed for the corresponding source IP address

2016-03-23 Thread Nick Livens (JIRA) 

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

Nick Livens reassigned CLOUDSTACK-9320:
---

Assignee: Nick Livens

> Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last 
> Internal Load Balancer rule is removed for the corresponding source IP address
> 
>
> Key: CLOUDSTACK-9320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9320
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Third-Party Bugs
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.0
>
>
> Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last 
> Internal Load Balancer rule is removed for the corresponding source IP 
> address.
> This not the expected behavior with feature Internal LB, refer the following 
> documentation of the feature Internal LB:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers
> InternalLBVM is only getting destroyed when we restart the Internal LB 
> network with cleanup (or) delete the network.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9320) InternalLBVM is not getting destroyed when the last Internal Load Balancer rule is removed for the corresponding source IP address

2016-03-23 Thread Nick Livens (JIRA) 

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

Nick Livens updated CLOUDSTACK-9320:

Summary: InternalLBVM is not getting destroyed when the last Internal Load 
Balancer rule is removed for the corresponding source IP address  (was: Nuage 
VSP SDN Plugin: InternalLBVM is not getting destroyed when the last Internal 
Load Balancer rule is removed for the corresponding source IP address)

> InternalLBVM is not getting destroyed when the last Internal Load Balancer 
> rule is removed for the corresponding source IP address
> --
>
> Key: CLOUDSTACK-9320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9320
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Third-Party Bugs
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.0
>
>
> Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last 
> Internal Load Balancer rule is removed for the corresponding source IP 
> address.
> This not the expected behavior with feature Internal LB, refer the following 
> documentation of the feature Internal LB:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers
> InternalLBVM is only getting destroyed when we restart the Internal LB 
> network with cleanup (or) delete the network.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's haproxy

2016-03-23 Thread Mani Prashanth Varma Manthena (JIRA) 
Mani Prashanth Varma Manthena created CLOUDSTACK-9321:
-

 Summary: Multiple Internal LB rules (more than one Internal LB 
rule with same source IP address) are not getting resolved in the corresponding 
InternalLbVm instance's haproxy.cfg file
 Key: CLOUDSTACK-9321
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Reporter: Mani Prashanth Varma Manthena
Priority: Critical
 Fix For: 4.9.0


Multiple Internal LB rules (more than one Internal LB rule with same source IP 
address) are not getting resolved in the corresponding InternalLbVm instance's 
haproxy.cfg file.

Moreover, each time a new Internal LB rule is added to the corresponding 
InternalLbVm instance, it replaces the existing one.

Thus, traffic corresponding to these un-resolved (old) Internal LB rules are 
getting dropped by the InternalLbVm instance.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's haprox

2016-03-23 Thread Nick Livens (JIRA) 

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

Nick Livens reassigned CLOUDSTACK-9321:
---

Assignee: Nick Livens

> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> --
>
> Key: CLOUDSTACK-9321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file.
> Moreover, each time a new Internal LB rule is added to the corresponding 
> InternalLbVm instance, it replaces the existing one.
> Thus, traffic corresponding to these un-resolved (old) Internal LB rules are 
> getting dropped by the InternalLbVm instance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9320) InternalLBVM is not getting destroyed when the last Internal Load Balancer rule is removed for the corresponding source IP address

2016-03-23 Thread Nick Livens (JIRA) 

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

Nick Livens updated CLOUDSTACK-9320:

Description: 
InternalLBVM is not getting destroyed when the last Internal Load Balancer rule 
is removed for the corresponding source IP address.

This not the expected behavior with feature Internal LB, refer the following 
documentation of the feature Internal LB:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers

InternalLBVM is only getting destroyed when we restart the Internal LB network 
with cleanup (or) delete the network.


  was:
Nuage VSP SDN Plugin: InternalLBVM is not getting destroyed when the last 
Internal Load Balancer rule is removed for the corresponding source IP address.

This not the expected behavior with feature Internal LB, refer the following 
documentation of the feature Internal LB:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers

InternalLBVM is only getting destroyed when we restart the Internal LB network 
with cleanup (or) delete the network.



> InternalLBVM is not getting destroyed when the last Internal Load Balancer 
> rule is removed for the corresponding source IP address
> --
>
> Key: CLOUDSTACK-9320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9320
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Third-Party Bugs
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.0
>
>
> InternalLBVM is not getting destroyed when the last Internal Load Balancer 
> rule is removed for the corresponding source IP address.
> This not the expected behavior with feature Internal LB, refer the following 
> documentation of the feature Internal LB:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers
> InternalLBVM is only getting destroyed when we restart the Internal LB 
> network with cleanup (or) delete the network.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8302) Cleanup snapshot on KVM with RBD

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-8302:


Github user kiwiflyer commented on the pull request:

https://github.com/apache/cloudstack/pull/1230#issuecomment-200347989
  
@DaanHoogland 

So I've been digging into this a bit. I could be very wrong here, but it 
seems that XenserverSnapshotStrategy is a very inaccurate description of what 
this class is actually doing. It seems to be very general and based on some 
investigation being used for KVM as well. This might be an old artifact of the 
original feature being Xen specific, until others re-purposed it for other 
hypervisors.

Mike @mike-tutkowski mentioned something to this effect very recently in 
this PR: https://github.com/apache/cloudstack/pull/1441


> Cleanup snapshot on KVM with RBD
> 
>
> Key: CLOUDSTACK-8302
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8302
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.4.0, 4.4.1, 4.4.2
> Environment: CloudStack 4.4.2 + KVM on CentOS 6.6 + Ceph/RBD 0.80.8
>Reporter: Star Guo
>Assignee: Wido den Hollander
>Priority: Critical
>
> I just build a lab with CloudStack 4.4.2 + CentOS 6.6 KVM + Ceph/RBD 0.80.8.
> I deploy an instance on RBD and I create the ROOT volume snapshots. When 
> delete a snapshot the UI show OK, but the snapshot of the volume in the RBD 
> pool is still exist.
> And I find the code in 
> com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java: 
> …
> @Override
> public Answer deleteSnapshot(DeleteCommand cmd) {
> return new Answer(cmd);
> }
> …
> deleteSnapshot() does not be implememented. And I also find the code:
> ...
> @Override
> public Answer createTemplateFromSnapshot(CopyCommand cmd) {
> return null;  //To change body of implemented methods use File | 
> Settings | File Templates.
> }
> ...
> So does createTenokateFromSnapshot(). I just look for it in MASTER branch but 
> not do that yet. Will CloudStack Dev Team plan to do that ? Thanks .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user ProjectMoon commented on the pull request:

https://github.com/apache/cloudstack/pull/1450#issuecomment-200345827
  
I added a basic test now and moved the method out @rafaelweingartner. Maybe 
there are more scenarios that can be tested?


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8302) Cleanup snapshot on KVM with RBD

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-8302:


Github user andrijapanic commented on the pull request:

https://github.com/apache/cloudstack/pull/1230#issuecomment-200350271
  
I believe this is the reason Dmytro edit it, since it handles KVM stuff
also...

On 23 March 2016 at 14:40, Simon Weller  wrote:

> @DaanHoogland 
>
> So I've been digging into this a bit. I could be very wrong here, but it
> seems that XenserverSnapshotStrategy is a very inaccurate description of
> what this class is actually doing. It seems to be very general and based 
on
> some investigation being used for KVM as well. This might be an old
> artifact of the original feature being Xen specific, until others
> re-purposed it for other hypervisors.
>
> Mike @mike-tutkowski  mentioned
> something to this effect very recently in this PR: #1441
> 
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub
> 
>



-- 

Andrija Panić



> Cleanup snapshot on KVM with RBD
> 
>
> Key: CLOUDSTACK-8302
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8302
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.4.0, 4.4.1, 4.4.2
> Environment: CloudStack 4.4.2 + KVM on CentOS 6.6 + Ceph/RBD 0.80.8
>Reporter: Star Guo
>Assignee: Wido den Hollander
>Priority: Critical
>
> I just build a lab with CloudStack 4.4.2 + CentOS 6.6 KVM + Ceph/RBD 0.80.8.
> I deploy an instance on RBD and I create the ROOT volume snapshots. When 
> delete a snapshot the UI show OK, but the snapshot of the volume in the RBD 
> pool is still exist.
> And I find the code in 
> com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java: 
> …
> @Override
> public Answer deleteSnapshot(DeleteCommand cmd) {
> return new Answer(cmd);
> }
> …
> deleteSnapshot() does not be implememented. And I also find the code:
> ...
> @Override
> public Answer createTemplateFromSnapshot(CopyCommand cmd) {
> return null;  //To change body of implemented methods use File | 
> Settings | File Templates.
> }
> ...
> So does createTenokateFromSnapshot(). I just look for it in MASTER branch but 
> not do that yet. Will CloudStack Dev Team plan to do that ? Thanks .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9322) Support for Internal LB fuctionality with Nuage VSP SDN Plugin including Marvin tests

2016-03-23 Thread Mani Prashanth Varma Manthena (JIRA) 
Mani Prashanth Varma Manthena created CLOUDSTACK-9322:
-

 Summary: Support for Internal LB fuctionality with Nuage VSP SDN 
Plugin including Marvin tests
 Key: CLOUDSTACK-9322
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9322
 Project: CloudStack
  Issue Type: Task
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Network Controller
Reporter: Mani Prashanth Varma Manthena
 Fix For: 4.9.0


1) UI changes to support LB provider “InternalLbVm” during VPC offering 
creation.

2) Bug fix for CLOUDSTACK-9320.

3) Nuage VSP SDN Plugin related enhancements for VPC network functionality.

4) Marvin test coverage for Internal LB support on master with Nuage VSP SDN 
Plugin.

5) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).

6) PyFlakes & PEP8 compliance with our Marvin test code.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8800) Improve the listVirtualMachines API call to include memory utilization information for a VM

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-8800:


Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-200473159
  
Can we continue the conversation at #1444 please.  This commit has been 
reverted and has been pulled into #1444 to continue QA of the code.  Please 
come contribute at #1444 and continue getting this code ready for production.  
Thx...


> Improve the listVirtualMachines API call to include memory utilization 
> information for a VM
> ---
>
> Key: CLOUDSTACK-8800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Maneesha
>Assignee: Maneesha
> Fix For: 4.6.1
>
>
> Currently the feature of memory utilization is not available via API call 
> (listVirtualMachines).
> https://cloudstack.apache.org/api/apidocs-4.5/root_admin/listVirtualMachines.html
>  
> The listVirtualMachine get its values from the "user_vm_view" table in the 
> database. Currently it shows the CPU utilization of the VM's.
> The only way to find out the memory utilization of VM's running on XenServer, 
> is to run the "xentop" command on the pool master of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

2016-03-23 Thread Milamber (JIRA) 

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

Milamber commented on CLOUDSTACK-9319:
--


Related with CLOUDSTACK-9255 I think

https://issues.apache.org/jira/browse/CLOUDSTACK-9255

> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9322) Support for Internal LB fuctionality with Nuage VSP SDN Plugin including Marvin tests

2016-03-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9322:


GitHub user prashanthvarma opened a pull request:

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

CLOUDSTACK-9322: Support for Internal LB fuctionality with Nuage VSP SDN 
Plugin including Marvin tests

Task: https://issues.apache.org/jira/browse/CLOUDSTACK-9322

PR contents:
1) UI changes to support LB provider “InternalLbVm” during VPC offering 
creation.
2) Bug fix for CLOUDSTACK-9320.
3) Nuage VSP SDN Plugin related enhancements for VPC network functionality.
4) Marvin test coverage for Internal LB support on master with Nuage VSP 
SDN Plugin.
5) Enhancements on our exiting Marvin test code (nuagevsp plugins 
directory).
6) PyFlakes & PEP8 compliance with our Marvin test code.

Test run:
CloudStack$ nosetests --with-marvin --marvin-config=nuage_ant.cfg 
test/integration/plugins/nuagevsp/ -a tags=nuagevsp

Test results:
Test user data and password reset functionality with Nuage VSP SDN plugin 
... === TestName: test_nuage_UserDataPasswordReset | Status : SUCCESS ===
ok
Test Nuage VSP VPC Offering with different combinations of LB service 
providers ... === TestName: test_01_nuage_internallb_vpc_Offering | Status : 
SUCCESS ===
ok
Test Nuage VSP VPC Network Offering with and without Internal LB service 
... === TestName: test_02_nuage_internallb_vpc_network_offering | Status : 
SUCCESS ===
ok
Test Nuage VSP VPC Networks with and without Internal LB service ... === 
TestName: test_03_nuage_internallb_vpc_networks | Status : SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with different combinations of 
Internal LB rules ... === TestName: test_04_nuage_internallb_rules | Status : 
SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality by performing (wget) traffic 
tests within a VPC ... === TestName: test_05_nuage_internallb_traffic | Status 
: SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with different LB algorithms 
by performing (wget) traffic tests ... === TestName: 
test_06_nuage_internallb_algorithms_traffic | Status : SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with restarts of VPC network 
components by performing (wget) ... === TestName: 
test_07_nuage_internallb_vpc_network_restarts_traffic | Status : SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with InternalLbVm appliance 
operations by performing (wget) ... === TestName: 
test_08_nuage_internallb_appliance_operations_traffic | Status : SUCCESS ===
ok
Test Basic VPC Network Functionality with Nuage VSP SDN plugin ... === 
TestName: test_nuage_vpc_network | Status : SUCCESS ===
ok
Test Nuage VSP SDN plugin with basic Isolated Network functionality ... === 
TestName: test_nuage_vsp | Status : SUCCESS ===
ok

--
Ran 11 tests in 12094.705s

OK

Test run logs:



PEP8 & PyFlakes Compliance:
CloudStack$ pep8 --max-line-length=150 
test/integration/plugins/nuagevsp/*.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/nuageTestCase.py
CloudStack$ pyflakes 
test/integration/plugins/nuagevsp/test_nuage_password_reset.py
CloudStack$ pyflakes 
test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py
CloudStack$ pyflakes 
test/integration/plugins/nuagevsp/test_nuage_vpc_network.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/test_nuage_vsp.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/*.py

#CLOUDSTACK-9322


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

$ git pull https://github.com/prashanthvarma/cloudstack master

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

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


commit be67e5cf0649e906291883d974873fb9f49aaff2
Author: Nick Livens 
Date:   2016-02-18T10:03:34Z

CLOUDSTACK-9322 : Changes to support InternalLbVm with Nuage VSP plugin

commit 7f811d9962e4112ac789129c3e73c4652db00c54
Author: Nick Livens 
Date:   2016-03-21T13:34:18Z

CLOUDSTACK-9320 : InternalLBVM is not getting destroyed when the last 
Internal Load Balancer rule is removed for the corresponding source IP address

commit 12085aae2caa4562dd7740d857e21f746d5a7748
Author: Prashanth Manthena 
Date:   2016-03-23T14:59:41Z

CLOUDSTACK-9322 : Marvin tests for Internal Lb with Nuage VSP




> Support for Internal LB fuctionality with Nuage VSP SDN Plugin including 
> Marv

[jira] [Updated] (CLOUDSTACK-9322) Support for Internal LB fuctionality with Nuage VSP SDN Plugin including Marvin tests

2016-03-23 Thread Mani Prashanth Varma Manthena (JIRA) 

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

Mani Prashanth Varma Manthena updated CLOUDSTACK-9322:
--
Description: 
PR: https://github.com/apache/cloudstack/pull/1452

PR contents:
1) UI changes to support LB provider “InternalLbVm” during VPC offering 
creation.
2) Bug fix for CLOUDSTACK-9320.
3) Nuage VSP SDN Plugin related enhancements for VPC network functionality.
4) Marvin test coverage for Internal LB support on master with Nuage VSP SDN 
Plugin.
5) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
6) PyFlakes & PEP8 compliance with our Marvin test code.

Test run:
CloudStack$ nosetests --with-marvin --marvin-config=nuage_ant.cfg 
test/integration/plugins/nuagevsp/ -a tags=nuagevsp

Test results:
Test user data and password reset functionality with Nuage VSP SDN plugin ... 
=== TestName: test_nuage_UserDataPasswordReset | Status : SUCCESS ===
ok
Test Nuage VSP VPC Offering with different combinations of LB service providers 
... === TestName: test_01_nuage_internallb_vpc_Offering | Status : SUCCESS ===
ok
Test Nuage VSP VPC Network Offering with and without Internal LB service ... 
=== TestName: test_02_nuage_internallb_vpc_network_offering | Status : SUCCESS 
===
ok
Test Nuage VSP VPC Networks with and without Internal LB service ... === 
TestName: test_03_nuage_internallb_vpc_networks | Status : SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with different combinations of 
Internal LB rules ... === TestName: test_04_nuage_internallb_rules | Status : 
SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality by performing (wget) traffic tests 
within a VPC ... === TestName: test_05_nuage_internallb_traffic | Status : 
SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with different LB algorithms by 
performing (wget) traffic tests ... === TestName: 
test_06_nuage_internallb_algorithms_traffic | Status : SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with restarts of VPC network 
components by performing (wget) ... === TestName: 
test_07_nuage_internallb_vpc_network_restarts_traffic | Status : SUCCESS ===
ok
Test Nuage VSP VPC Internal LB functionality with InternalLbVm appliance 
operations by performing (wget) ... === TestName: 
test_08_nuage_internallb_appliance_operations_traffic | Status : SUCCESS ===
ok
Test Basic VPC Network Functionality with Nuage VSP SDN plugin ... === 
TestName: test_nuage_vpc_network | Status : SUCCESS ===
ok
Test Nuage VSP SDN plugin with basic Isolated Network functionality ... === 
TestName: test_nuage_vsp | Status : SUCCESS ===
ok

Ran 11 tests in 12094.705s

OK

PEP8 & PyFlakes Compliance:
CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/nuageTestCase.py
CloudStack$ pyflakes 
test/integration/plugins/nuagevsp/test_nuage_password_reset.py
CloudStack$ pyflakes 
test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/test_nuage_vpc_network.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/test_nuage_vsp.py
CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py


  was:
1) UI changes to support LB provider “InternalLbVm” during VPC offering 
creation.

2) Bug fix for CLOUDSTACK-9320.

3) Nuage VSP SDN Plugin related enhancements for VPC network functionality.

4) Marvin test coverage for Internal LB support on master with Nuage VSP SDN 
Plugin.

5) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).

6) PyFlakes & PEP8 compliance with our Marvin test code.



> Support for Internal LB fuctionality with Nuage VSP SDN Plugin including 
> Marvin tests
> -
>
> Key: CLOUDSTACK-9322
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9322
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Mani Prashanth Varma Manthena
> Fix For: 4.9.0
>
>
> PR: https://github.com/apache/cloudstack/pull/1452
> PR contents:
> 1) UI changes to support LB provider “InternalLbVm” during VPC offering 
> creation.
> 2) Bug fix for CLOUDSTACK-9320.
> 3) Nuage VSP SDN Plugin related enhancements for VPC network functionality.
> 4) Marvin test coverage for Internal LB support on master with Nuage VSP SDN 
> Plugin.
> 5) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 6) PyFlakes & PEP8 compliance with our Marvin test code.
> Test run:
> CloudStack$ nosetests --with-marvin --marvin-config=nuage_ant.cfg 
> test/integration/plugins/nuagevsp/ -a tags=nuagevsp
> Test results:
> Test user data and p

[jira] [Created] (CLOUDSTACK-9323) Cancelling host maintenance results in ""Internal error cancelling maintenance.”

2016-03-23 Thread Abhinandan Prateek (JIRA) 
Abhinandan Prateek created CLOUDSTACK-9323:
--

 Summary: Cancelling host maintenance results in ""Internal error 
cancelling maintenance.”
 Key: CLOUDSTACK-9323
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9323
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Abhinandan Prateek
 Fix For: Future


When we try to cancel the host from maintenance, all the hosts are complaining 
""Internal error cancelling maintenance.” but successfully enabling the host 
back.
In both scenarios like host is in up or disconnected state.
This causes problem when we programmatically cancel maintenance….



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)