[jira] [Created] (CLOUDSTACK-9868) internal LB for VPC tier is broken

[Abhinandan Prateek (JIRA)]

Abhinandan Prateek created CLOUDSTACK-9868:
--

 Summary: internal LB for VPC tier is broken
 Key: CLOUDSTACK-9868
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9868
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VPC
Affects Versions: 4.9.0
Reporter: Abhinandan Prateek
Priority: Blocker
 Fix For: 4.10.1.0



660
2017-04-05 09:29:02,504 WARN  [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-73:ctx-aca51da1 job-521791/job-521801 ctx-d1bd5a40) 
shutdownNetworkRules failed during the network Ntwk[1557|Guest|60] shutdown due 
to
com.cloud.utils.exception.CloudRuntimeException: Unable to start a VM due to 
concurrent operation
at 
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:618)
at 
org.apache.cloudstack.network.lb.InternalLoadBalancerVMManagerImpl.startInternalLbVm(InternalLoadBalancerVMManagerImpl.java:826)
 <- Second Invocation, causes concurrent exception
at 
org.apache.cloudstack.network.lb.InternalLoadBalancerVMManagerImpl.startInternalLbVms(InternalLoadBalancerVMManagerImpl.java:581)
at 
org.apache.cloudstack.network.lb.InternalLoadBalancerVMManagerImpl.deployInternalLbVm(InternalLoadBalancerVMManagerImpl.java:565)
at 
org.apache.cloudstack.network.element.InternalLoadBalancerElement.applyLBRules(InternalLoadBalancerElement.java:335)
at 
com.cloud.network.lb.LoadBalancingRulesManagerImpl.applyLbRules(LoadBalancingRulesManagerImpl.java:1842)
at 
com.cloud.network.lb.LoadBalancingRulesManagerImpl.applyLbRules(LoadBalancingRulesManagerImpl.java:2439)
at 
com.cloud.network.lb.LoadBalancingRulesManagerImpl.applyLoadBalancerRules(LoadBalancingRulesManagerImpl.java:1878)
at 
com.cloud.network.lb.LoadBalancingRulesManagerImpl.revokeLoadBalancersForNetwork(LoadBalancingRulesManagerImpl.java:1815)
at sun.reflect.GeneratedMethodAccessor571.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy160.revokeLoadBalancersForNetwork(Unknown Source)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkResources(NetworkOrchestrator.java:2878)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2236)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetwork(NetworkOrchestrator.java:2162)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:1053)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:950)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1314)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:997)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:787)
at 
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:616)
at 
org.apache.cloudstack.network.lb.InternalLoadBalancerVMManagerImpl.startInternalLbVm(InternalLoadBalancerVMManagerImpl.java:826)
 <- First Invocation
at 
org.apache.cloudstack.network.lb.InternalLoadBalancerVMManagerImpl.startInternalLbVms(InternalLoadBalancerVMManagerImpl.java:581)
at 
org.apache.cloudstack.network.lb.InternalLoadBalancerVMManagerImpl.deployInternalLbVm(InternalLoadBalancerVMManagerImpl.java:565)
at 
org.apache.cloudstack.network.element.InternalLoadBalancerElement.implementInternalLbVms(InternalLoadBalancerElement.java:201)
at 
org.apache.cloudstack.network.element.InternalLoadBalancerElement.implement(InternalLoadBalancerElement.java:170)
at 

[jira] [Commented] (CLOUDSTACK-9864) cleanup stale worker VMs after job expiry time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9864:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2030
  
Trillian test result (tid-983)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 51519 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2030-t983-vmware-55u3.zip
Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_vgpu_enabled_vm.py
Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py
Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
Intermitten failure detected: 
/marvin/tests/smoke/test_routers_network_ops.py
Intermitten failure detected: /marvin/tests/smoke/test_routers.py
Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.py
Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Test completed. 48 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_test_vm_volume_snapshot | `Failure` | 322.23 | test_vm_snapshots.py
test_04_rvpc_privategw_static_routes | `Failure` | 888.45 | 
test_privategw_acl.py
test_01_vpc_site2site_vpn | Success | 371.71 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 166.99 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 593.09 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 354.29 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 742.66 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 675.76 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1534.04 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 751.75 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 704.82 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1374.94 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 30.73 | test_volumes.py
test_06_download_detached_volume | Success | 60.53 | test_volumes.py
test_05_detach_volume | Success | 105.26 | test_volumes.py
test_04_delete_attached_volume | Success | 10.18 | test_volumes.py
test_03_download_attached_volume | Success | 20.32 | test_volumes.py
test_02_attach_volume | Success | 58.72 | test_volumes.py
test_01_create_volume | Success | 519.39 | test_volumes.py
test_change_service_offering_for_vm_with_snapshots | Success | 548.99 | 
test_vm_snapshots.py
test_03_delete_vm_snapshots | Success | 275.23 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 232.04 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 161.65 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 242.48 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.83 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.25 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 60.94 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.14 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.13 | test_vm_life_cycle.py
test_02_start_vm | Success | 20.25 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.14 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 206.29 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.06 | test_templates.py
test_04_extract_template | Success | 10.20 | test_templates.py
test_03_delete_template | Success | 5.09 | test_templates.py
test_02_edit_template | Success | 90.13 | test_templates.py
test_01_create_template | Success | 121.06 | test_templates.py
test_10_destroy_cpvm | Success | 266.87 | test_ssvm.py
test_09_destroy_ssvm | Success | 268.71 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.52 | test_ssvm.py
test_07_reboot_ssvm | Success | 188.45 | test_ssvm.py
test_06_stop_cpvm | Success | 176.88 | test_ssvm.py
test_05_stop_ssvm | Success | 203.78 | test_ssvm.py
test_04_cpvm_internals | Success | 1.20 | test_ssvm.py
test_03_ssvm_internals | Success | 3.39 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2034
  
Trillian test result (tid-984)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 45224 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2034-t984-vmware-55u3.zip
Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
Intermitten failure detected: 
/marvin/tests/smoke/test_routers_network_ops.py
Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.py
Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
Test completed. 45 look ok, 4 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_test_vm_volume_snapshot | `Failure` | 246.46 | test_vm_snapshots.py
test_04_rvpc_privategw_static_routes | `Failure` | 788.73 | 
test_privategw_acl.py
ContextSuite context=TestVPCRedundancy>:setup | `Error` | 0.00 | 
test_vpc_redundant.py
test_02_list_snapshots_with_removed_data_store | `Error` | 80.68 | 
test_snapshots.py
test_02_list_snapshots_with_removed_data_store | `Error` | 85.76 | 
test_snapshots.py
test_01_vpc_site2site_vpn | Success | 350.15 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 156.55 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 576.51 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 408.53 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 649.74 | test_vpc_router_nics.py
test_09_delete_detached_volume | Success | 30.73 | test_volumes.py
test_06_download_detached_volume | Success | 60.45 | test_volumes.py
test_05_detach_volume | Success | 100.22 | test_volumes.py
test_04_delete_attached_volume | Success | 10.14 | test_volumes.py
test_03_download_attached_volume | Success | 20.24 | test_volumes.py
test_02_attach_volume | Success | 53.66 | test_volumes.py
test_01_create_volume | Success | 518.34 | test_volumes.py
test_03_delete_vm_snapshots | Success | 285.17 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 232.03 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 161.59 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 221.79 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.64 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.21 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 111.02 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.07 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.12 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.13 | test_vm_life_cycle.py
test_02_start_vm | Success | 20.17 | test_vm_life_cycle.py
test_01_stop_vm | Success | 5.09 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 231.53 | test_templates.py
test_08_list_system_templates | Success | 0.02 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.04 | test_templates.py
test_04_extract_template | Success | 10.20 | test_templates.py
test_03_delete_template | Success | 5.08 | test_templates.py
test_02_edit_template | Success | 90.16 | test_templates.py
test_01_create_template | Success | 105.66 | test_templates.py
test_10_destroy_cpvm | Success | 236.52 | test_ssvm.py
test_09_destroy_ssvm | Success | 268.33 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.28 | test_ssvm.py
test_07_reboot_ssvm | Success | 158.28 | test_ssvm.py
test_06_stop_cpvm | Success | 176.45 | test_ssvm.py
test_05_stop_ssvm | Success | 178.30 | test_ssvm.py
test_04_cpvm_internals | Success | 0.95 | test_ssvm.py
test_03_ssvm_internals | Success | 3.38 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.10 | test_ssvm.py
test_01_snapshot_root_disk | Success | 25.98 | test_snapshots.py
test_04_change_offering_small | Success | 96.70 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py
test_01_create_service_offering | Success | 0.08 | test_service_offerings.py
test_02_sys_template_ready | Success 

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
Trillian test result (tid-986)
Environment: kvm-ubuntu (x2), Advanced Networking with Mgmt server u
Total time taken: 31695 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2033-t986-kvm-ubuntu.zip
Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Test completed. 46 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 359.34 
| test_vpc_redundant.py
test_04_rvpc_privategw_static_routes | `Failure` | 290.91 | 
test_privategw_acl.py
test_02_list_snapshots_with_removed_data_store | `Error` | 0.04 | 
test_snapshots.py
test_01_vpc_site2site_vpn | Success | 155.71 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 56.20 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 225.62 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 269.50 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 540.38 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 522.49 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1399.25 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 545.06 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 751.08 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 156.59 | test_volumes.py
test_08_resize_volume | Success | 161.58 | test_volumes.py
test_07_resize_fail | Success | 161.54 | test_volumes.py
test_06_download_detached_volume | Success | 161.57 | test_volumes.py
test_05_detach_volume | Success | 155.92 | test_volumes.py
test_04_delete_attached_volume | Success | 156.32 | test_volumes.py
test_03_download_attached_volume | Success | 151.62 | test_volumes.py
test_02_attach_volume | Success | 100.51 | test_volumes.py
test_01_create_volume | Success | 711.44 | test_volumes.py
test_deploy_vm_multiple | Success | 242.77 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.71 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 30.98 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 130.88 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 131.08 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.20 | test_vm_life_cycle.py
test_01_stop_vm | Success | 45.39 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 50.65 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.09 | test_templates.py
test_04_extract_template | Success | 5.24 | test_templates.py
test_03_delete_template | Success | 5.12 | test_templates.py
test_02_edit_template | Success | 90.13 | test_templates.py
test_01_create_template | Success | 65.61 | test_templates.py
test_10_destroy_cpvm | Success | 167.08 | test_ssvm.py
test_09_destroy_ssvm | Success | 164.14 | test_ssvm.py
test_08_reboot_cpvm | Success | 132.04 | test_ssvm.py
test_07_reboot_ssvm | Success | 103.53 | test_ssvm.py
test_06_stop_cpvm | Success | 137.37 | test_ssvm.py
test_05_stop_ssvm | Success | 164.04 | test_ssvm.py
test_04_cpvm_internals | Success | 1.81 | test_ssvm.py
test_03_ssvm_internals | Success | 3.41 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py
test_01_snapshot_root_disk | Success | 11.29 | test_snapshots.py
test_04_change_offering_small | Success | 210.43 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py
test_01_create_service_offering | Success | 0.26 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py

[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9764:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1935
  
@nvazquez now everything seems to be ok
LGTM.

Great job!


> Delete domain failure due to Account Cleanup task
> -
>
> Key: CLOUDSTACK-9764
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> It was noticed in production environments that {{deleteDomain}} task failed 
> for domains with multiple accounts and resources. Examining logs it was found 
> out that if Account Cleanup Task got executed after domain (and all of its 
> subchilds) got marked as Inactive; and before delete domain task finishes, it 
> produces a failure.
> {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} 
> seconds looking for:
> * Removed accounts
> * Disabled accounts
> * Inactive domains
> As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive 
> before deleting them, when {{AccountCleanupTask}} is executed, it removes 
> marked domains. When there are resources to cleanup on domain accounts, 
> domain is not found throwing exception: 
> {{com.cloud.exception.InvalidParameterValueException: Please specify a valid 
> domain ID}}
> h3. Example
> {{account.cleanup.interval}} = 100
> {noformat}
> 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] 
> (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END===  10.39.251.17 -- GET  
> command=deleteDomain=1910a3dc-6fa6-457b-ab3a-602b0cfb6686=true=json&_=1485439623475
> ...
> // Domain and its subchilds marked as Inactive
> 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 
> as Inactive before actually deleting it
> 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=27
> 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=28
> 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=29
> ...
> // AccountCleanupTask removes Inactive domain id=29, no rollback for it
> 2017-01-26 06:07:44,285 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup
> 2017-01-26 06:07:44,287 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup
> 2017-01-26 06:07:44,289 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup
> 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27
> 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28
> 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29
> 2017-01-26 06:07:44,319 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 disabled projects to cleanup
> ...
> // Failure 

[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9764:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1935
  
@rafaelweingartner thanks for reviewing again! Minor refactor pushed


> Delete domain failure due to Account Cleanup task
> -
>
> Key: CLOUDSTACK-9764
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> It was noticed in production environments that {{deleteDomain}} task failed 
> for domains with multiple accounts and resources. Examining logs it was found 
> out that if Account Cleanup Task got executed after domain (and all of its 
> subchilds) got marked as Inactive; and before delete domain task finishes, it 
> produces a failure.
> {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} 
> seconds looking for:
> * Removed accounts
> * Disabled accounts
> * Inactive domains
> As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive 
> before deleting them, when {{AccountCleanupTask}} is executed, it removes 
> marked domains. When there are resources to cleanup on domain accounts, 
> domain is not found throwing exception: 
> {{com.cloud.exception.InvalidParameterValueException: Please specify a valid 
> domain ID}}
> h3. Example
> {{account.cleanup.interval}} = 100
> {noformat}
> 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] 
> (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END===  10.39.251.17 -- GET  
> command=deleteDomain=1910a3dc-6fa6-457b-ab3a-602b0cfb6686=true=json&_=1485439623475
> ...
> // Domain and its subchilds marked as Inactive
> 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 
> as Inactive before actually deleting it
> 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=27
> 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=28
> 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=29
> ...
> // AccountCleanupTask removes Inactive domain id=29, no rollback for it
> 2017-01-26 06:07:44,285 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup
> 2017-01-26 06:07:44,287 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup
> 2017-01-26 06:07:44,289 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup
> 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27
> 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28
> 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29
> 2017-01-26 06:07:44,319 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 disabled projects to cleanup
> ...
> // Failure due to 

[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9764:


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

https://github.com/apache/cloudstack/pull/1935#discussion_r110421451
  
--- Diff: server/test/com/cloud/user/DomainManagerImplTest.java ---
@@ -134,4 +164,69 @@ public void testFindDomainByIdOrPathValidId() {
 Assert.assertEquals(domain, domainManager.findDomainByIdOrPath(1L, 
"/validDomain/"));
 }
 
+@Test(expected=InvalidParameterValueException.class)
+public void testDeleteDomainNullDomain() {
+Mockito.when(_domainDao.findById(DOMAIN_ID)).thenReturn(null);
+domainManager.deleteDomain(DOMAIN_ID, testDomainCleanup);
+}
+
+@Test(expected=PermissionDeniedException.class)
+public void testDeleteDomainRootDomain() {
+
Mockito.when(_domainDao.findById(Domain.ROOT_DOMAIN)).thenReturn(domain);
+domainManager.deleteDomain(Domain.ROOT_DOMAIN, testDomainCleanup);
+}
+
+@Test
+public void testDeleteDomainNoCleanup() {
+domainManager.deleteDomain(DOMAIN_ID, testDomainCleanup);
+Mockito.verify(domainManager).deleteDomain(domain, 
testDomainCleanup);
+
Mockito.verify(domainManager).removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain);
+Mockito.verify(domainManager).cleanupDomainOfferings(DOMAIN_ID);
+Mockito.verify(lock).unlock();
+}
+
+@Test
+public void 
testRemoveDomainWithNoAccountsForCleanupNetworksOrDedicatedResourcesRemoveDomain()
 {
+
domainManager.removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain);
+
Mockito.verify(domainManager).publishRemoveEventsAndRemoveDomain(domain);
+}
+
+@Test(expected=CloudRuntimeException.class)
+public void 
testRemoveDomainWithNoAccountsForCleanupNetworksOrDedicatedResourcesDontRemoveDomain()
 {
+domainNetworkIds.add(2l);
+
domainManager.removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain);
+Mockito.verify(domainManager).failRemoveOperation(domain, 
domainAccountsForCleanup, domainNetworkIds, false);
+}
+
+@Test
+public void testPublishRemoveEventsAndRemoveDomainSuccessfulDelete() {
+domainManager.publishRemoveEventsAndRemoveDomain(domain);
+Mockito.verify(_messageBus).publish(Mockito.anyString(), 
Matchers.eq(DomainManager.MESSAGE_PRE_REMOVE_DOMAIN_EVENT),
+Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain));
+Mockito.verify(_messageBus).publish(Mockito.anyString(), 
Matchers.eq(DomainManager.MESSAGE_REMOVE_DOMAIN_EVENT),
+Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain));
+Mockito.verify(_domainDao).remove(DOMAIN_ID);
+}
+
+@Test(expected=CloudRuntimeException.class)
+public void testPublishRemoveEventsAndRemoveDomainExceptionDelete() {
+Mockito.when(_domainDao.remove(DOMAIN_ID)).thenReturn(false);
+domainManager.publishRemoveEventsAndRemoveDomain(domain);
+Mockito.verify(_messageBus).publish(Mockito.anyString(), 
Matchers.eq(DomainManager.MESSAGE_PRE_REMOVE_DOMAIN_EVENT),
+Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain));
+Mockito.verify(_messageBus, 
Mockito.never()).publish(Mockito.anyString(), 
Matchers.eq(DomainManager.MESSAGE_REMOVE_DOMAIN_EVENT),
+Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain));
+Mockito.verify(_domainDao).remove(DOMAIN_ID);
+}
+
+@Test
+public void testFailRemoveOperation() {
+try {
+domainManager.failRemoveOperation(domain, 
domainAccountsForCleanup, domainNetworkIds, true);
--- End diff --

Great, thanks!


> Delete domain failure due to Account Cleanup task
> -
>
> Key: CLOUDSTACK-9764
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> It was noticed in production environments that {{deleteDomain}} task failed 
> for domains with multiple accounts and resources. Examining logs it was found 
> out that if Account Cleanup Task got executed after domain (and all of its 
> subchilds) got marked as Inactive; and before delete domain task finishes, it 
> 

[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9764:


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

https://github.com/apache/cloudstack/pull/1935#discussion_r110421376
  
--- Diff: server/src/com/cloud/user/DomainManagerImpl.java ---
@@ -273,82 +284,145 @@ public boolean deleteDomain(long domainId, Boolean 
cleanup) {
 
 @Override
 public boolean deleteDomain(DomainVO domain, Boolean cleanup) {
-// mark domain as inactive
-s_logger.debug("Marking domain id=" + domain.getId() + " as " + 
Domain.State.Inactive + " before actually deleting it");
-domain.setState(Domain.State.Inactive);
-_domainDao.update(domain.getId(), domain);
-boolean rollBackState = false;
-boolean hasDedicatedResources = false;
+GlobalLock lock = getGlobalLock("AccountCleanup");
+if (lock == null) {
+s_logger.debug("Couldn't get the global lock");
+return false;
+}
+
+if (!lock.lock(30)) {
+s_logger.debug("Couldn't lock the db");
+return false;
+}
 
 try {
-long ownerId = domain.getAccountId();
-if ((cleanup != null) && cleanup.booleanValue()) {
-if (!cleanupDomain(domain.getId(), ownerId)) {
-rollBackState = true;
-CloudRuntimeException e =
-new CloudRuntimeException("Failed to clean up 
domain resources and sub domains, delete failed on domain " + domain.getName() 
+ " (id: " +
-domain.getId() + ").");
-e.addProxyObject(domain.getUuid(), "domainId");
-throw e;
-}
-} else {
-//don't delete the domain if there are accounts set for 
cleanup, or non-removed networks exist, or domain has dedicated resources
-List networkIds = 
_networkDomainDao.listNetworkIdsByDomain(domain.getId());
-List accountsForCleanup = 
_accountDao.findCleanupsForRemovedAccounts(domain.getId());
-List dedicatedResources = 
_dedicatedDao.listByDomainId(domain.getId());
-if (dedicatedResources != null && 
!dedicatedResources.isEmpty()) {
-s_logger.error("There are dedicated resources for the 
domain " + domain.getId());
-hasDedicatedResources = true;
-}
-if (accountsForCleanup.isEmpty() && networkIds.isEmpty() 
&& !hasDedicatedResources) {
-_messageBus.publish(_name, 
MESSAGE_PRE_REMOVE_DOMAIN_EVENT, PublishScope.LOCAL, domain);
-if (!_domainDao.remove(domain.getId())) {
-rollBackState = true;
-CloudRuntimeException e =
-new CloudRuntimeException("Delete failed on 
domain " + domain.getName() + " (id: " + domain.getId() +
-"); Please make sure all users and sub 
domains have been removed from the domain before deleting");
-e.addProxyObject(domain.getUuid(), "domainId");
-throw e;
-}
-_messageBus.publish(_name, 
MESSAGE_REMOVE_DOMAIN_EVENT, PublishScope.LOCAL, domain);
+// mark domain as inactive
+s_logger.debug("Marking domain id=" + domain.getId() + " as " 
+ Domain.State.Inactive + " before actually deleting it");
+domain.setState(Domain.State.Inactive);
+_domainDao.update(domain.getId(), domain);
+
+boolean rollBackState = false;
+
+try {
+long ownerId = domain.getAccountId();
+if (BooleanUtils.toBoolean(cleanup)) {
+tryCleanupDomain(domain, ownerId);
 } else {
-rollBackState = true;
-String msg = null;
-if (!accountsForCleanup.isEmpty()) {
-msg = accountsForCleanup.size() + " accounts to 
cleanup";
-} else if (!networkIds.isEmpty()) {
-msg = networkIds.size() + " non-removed networks";
-} else if (hasDedicatedResources) {
-msg = "dedicated resources.";
-}
+
removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain);
+}
 
-  

[jira] [Commented] (CLOUDSTACK-9719) [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9719:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1879
  
Thanks @sureshanaparti! I tested scenarios and work as expected! 
I attach some screenshots:

- Test scenario 1: Enable HA after VR created, stop VR, start VR.

![vr1](https://cloud.githubusercontent.com/assets/5295080/24807399/674c61ee-1b8e-11e7-8aeb-70d08056683b.PNG)

- Test scenario 2: HA enabled before VR created. deployed VM

![vr2](https://cloud.githubusercontent.com/assets/5295080/24807748/d78e51be-1b8f-11e7-902f-618d94edd654.PNG)




> [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery
> --
>
> Key: CLOUDSTACK-9719
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9719
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> After HA being triggered on VMware, some VMs fail to acquire DHCP address 
> from a VR. These VMs are live migrated as part of vCenter HA to another 
> available host before the VR and couldn't acquire DHCP address as VR is not 
> migrated yet and these VMs request failed to reach the VR.
> Resolving this requires manual intervention by the CloudStack administrator; 
> the router must be rebooted or the network restarted. This behavior is not 
> ideal and will prolong downtime caused by an HA event and there is no point 
> for the non-functional virtual router to even be running. CloudStack should 
> handle this situation by setting VR restart priority to high in the vCenter 
> when HA is enabled.



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

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


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
@blueorangutan package


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

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


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
Packaging result: ✔centos6 ✔centos7 ✔debian.


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2034
  
@blueorangutan test centos7 vmware-55u3


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2034
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been 
kicked to run smoke tests


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user blueorangutan commented on the issue:

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


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-627


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user blueorangutan commented on the issue:

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


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user rhtyd closed the pull request at:

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


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


GitHub user rhtyd reopened a pull request:

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

[4.9+][network blocker] CLOUDSTACK-9838: Allow ingress traffic between 
guest VMs via snat IPs

This enables the firewall/mangle tables rules to ACCEPT instead of RETURN, 
which
is the same behaviour as observed in ACS 4.5. By accepting the traffic, 
guest
VMs will be able to communicate tcp traffic between each other over snat 
public
IPs.

This is a regression from ACS 4.5, observed in ACS 4.9.2.0.
Pinging for review - @PaulAngus @borisstoyanov @DagSonsteboSB 
@abhinandanprateek @DaanHoogland and others

@blueorangutan package

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

$ git pull https://github.com/shapeblue/cloudstack CLOUDSTACK-9838

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

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


commit f4835294869f01def94618f2c206160ccb3b719f
Author: Rohit Yadav 
Date:   2017-04-07T11:44:18Z

CLOUDSTACK-9838: Allow ingress traffic between guest VMs via snat IPs

This enables the firewall/mangle tables rules to ACCEPT instead of RETURN, 
which
is the same behaviour as observed in ACS 4.5. By accepting the traffic, 
guest
VMs will be able to communicate tcp traffic between each other over snat 
public
IPs.

Signed-off-by: Rohit Yadav 




> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9867:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2035
  
@abhinandanprateek can you check/fix the build failures?


> VM snapshots - not charged for the primary storage they use up
> --
>
> Key: CLOUDSTACK-9867
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: Future
>
>
> Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
> storage. CloudStack has no mechanism to record the additional storage used by 
> these snapshots.  
> To add an additional usage metric that is “primary storage used by 
> snapshots”. 



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
@blueorangutan package


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

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


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2034
  
@borisstoyanov working now, I've rekicked packaging.


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9867:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2035
  
Packaging result: ✖centos6 ✖centos7 ✖debian. JID-626


> VM snapshots - not charged for the primary storage they use up
> --
>
> Key: CLOUDSTACK-9867
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: Future
>
>
> Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
> storage. CloudStack has no mechanism to record the additional storage used by 
> these snapshots.  
> To add an additional usage metric that is “primary storage used by 
> snapshots”. 



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2034
  
@rhtyd build failed with
`[ERROR] Failed to execute goal on project cloud-plugin-network-netscaler: 
Could not resolve dependencies for project 
org.apache.cloudstack:cloud-plugin-network-netscaler:jar:4.9.3.0-SNAPSHOT: 
Could not transfer artifact com.citrix.netscaler.nitro:sdx_nitro:jar:10.1 
from/to central (https://repo.maven.apache.org/maven2): Failed to transfer 
file: 
https://repo.maven.apache.org/maven2/com/citrix/netscaler/nitro/sdx_nitro/10.1/sdx_nitro-10.1.jar.
 Return code is: 503 , ReasonPhrase:backend read error. -> [Help 1]`

Any idea what's happening with this dependency?


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9867:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/2035
  
@blueorangutan package


> VM snapshots - not charged for the primary storage they use up
> --
>
> Key: CLOUDSTACK-9867
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: Future
>
>
> Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
> storage. CloudStack has no mechanism to record the additional storage used by 
> these snapshots.  
> To add an additional usage metric that is “primary storage used by 
> snapshots”. 



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

[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9867:


Github user blueorangutan commented on the issue:

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


> VM snapshots - not charged for the primary storage they use up
> --
>
> Key: CLOUDSTACK-9867
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: Future
>
>
> Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
> storage. CloudStack has no mechanism to record the additional storage used by 
> these snapshots.  
> To add an additional usage metric that is “primary storage used by 
> snapshots”. 



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

[jira] [Commented] (CLOUDSTACK-9864) cleanup stale worker VMs after job expiry time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9864:


Github user blueorangutan commented on the issue:

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


> cleanup stale worker VMs after job expiry time
> --
>
> Key: CLOUDSTACK-9864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9864
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>  Labels: vmware, vsphere, workers
>
> In the present code cleaning worker vms after a timeout is disabled, with the 
> documented reason that there is no API to query for related tasks in vcenter. 
> ACS has an expiry time for jobs and a cancel time for jobs.
> - Jobs that take longer then the expiry time will have their results be be 
> neglected.
> - Jobs that are cancelled are forcibly removed after the cancellation expity 
> time.
> Any worker remaining after expiry+cancellation will surely be stale and can 
> be removed.
> As some administrators may not want this behaviour there will be a setting 
> which by default is false that will guard against cleaning stale worker VMs.
> Stale worker VMs will be cleaned after 2 * (expiry-time + cancellation-time) 
> as a safe margin.
> related settings:
> job.expire.minutes: 1440
> job.cancel.threshold.minutes: 60
> vmware.clean.old.worker.vms: false (new)



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

[jira] [Commented] (CLOUDSTACK-9864) cleanup stale worker VMs after job expiry time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9864:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2030
  
@blueorangutan test centos7 vmware-55u3


> cleanup stale worker VMs after job expiry time
> --
>
> Key: CLOUDSTACK-9864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9864
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>  Labels: vmware, vsphere, workers
>
> In the present code cleaning worker vms after a timeout is disabled, with the 
> documented reason that there is no API to query for related tasks in vcenter. 
> ACS has an expiry time for jobs and a cancel time for jobs.
> - Jobs that take longer then the expiry time will have their results be be 
> neglected.
> - Jobs that are cancelled are forcibly removed after the cancellation expity 
> time.
> Any worker remaining after expiry+cancellation will surely be stale and can 
> be removed.
> As some administrators may not want this behaviour there will be a setting 
> which by default is false that will guard against cleaning stale worker VMs.
> Stale worker VMs will be cleaned after 2 * (expiry-time + cancellation-time) 
> as a safe margin.
> related settings:
> job.expire.minutes: 1440
> job.cancel.threshold.minutes: 60
> vmware.clean.old.worker.vms: false (new)



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/2034
  
Packaging result: ✖centos6 ✖centos7 ✔debian. JID-625


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9867:


GitHub user abhinandanprateek opened a pull request:

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

CLOUDSTACK-9867:VM snapshot on primary storage usage metrics



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

$ git pull https://github.com/shapeblue/cloudstack ir24

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

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


commit 8f9e93316c66907246be1d653da27ae9feb5a27c
Author: Abhinandan Prateek 
Date:   2017-03-22T06:54:19Z

CLOUDSTACK-9867:VM snapshot on primary storage usage metrics




> VM snapshots - not charged for the primary storage they use up
> --
>
> Key: CLOUDSTACK-9867
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: Future
>
>
> Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
> storage. CloudStack has no mechanism to record the additional storage used by 
> these snapshots.  
> To add an additional usage metric that is “primary storage used by 
> snapshots”. 



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

[jira] [Updated] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-9867:
---
Issue Type: Improvement  (was: Bug)

> VM snapshots - not charged for the primary storage they use up
> --
>
> Key: CLOUDSTACK-9867
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: Future
>
>
> Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
> storage. CloudStack has no mechanism to record the additional storage used by 
> these snapshots.  
> To add an additional usage metric that is “primary storage used by 
> snapshots”. 



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

[jira] [Created] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up

[Abhinandan Prateek (JIRA)]

Abhinandan Prateek created CLOUDSTACK-9867:
--

 Summary: VM snapshots - not charged for the primary storage they 
use up
 Key: CLOUDSTACK-9867
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.10.0.0
Reporter: Abhinandan Prateek
Assignee: Abhinandan Prateek
 Fix For: Future


Currently, when a user takes a VM snapshot, the snapshot is kept on primary 
storage. CloudStack has no mechanism to record the additional storage used by 
these snapshots.  
To add an additional usage metric that is “primary storage used by snapshots”. 




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

[jira] [Commented] (CLOUDSTACK-9864) cleanup stale worker VMs after job expiry time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9864:


Github user blueorangutan commented on the issue:

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


> cleanup stale worker VMs after job expiry time
> --
>
> Key: CLOUDSTACK-9864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9864
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>  Labels: vmware, vsphere, workers
>
> In the present code cleaning worker vms after a timeout is disabled, with the 
> documented reason that there is no API to query for related tasks in vcenter. 
> ACS has an expiry time for jobs and a cancel time for jobs.
> - Jobs that take longer then the expiry time will have their results be be 
> neglected.
> - Jobs that are cancelled are forcibly removed after the cancellation expity 
> time.
> Any worker remaining after expiry+cancellation will surely be stale and can 
> be removed.
> As some administrators may not want this behaviour there will be a setting 
> which by default is false that will guard against cleaning stale worker VMs.
> Stale worker VMs will be cleaned after 2 * (expiry-time + cancellation-time) 
> as a safe margin.
> related settings:
> job.expire.minutes: 1440
> job.cancel.threshold.minutes: 60
> vmware.clean.old.worker.vms: false (new)



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

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9591:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2022
  
Thanks @borisstoyanov 
@karuturi this is ready for merge now, thanks


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



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

[jira] [Assigned] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-9838:
---

Assignee: Rohit Yadav

> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


Github user blueorangutan commented on the issue:

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


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9838:


GitHub user rhtyd opened a pull request:

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

[4.9+][network blocker] CLOUDSTACK-9838: Allow ingress traffic between 
guest VMs via snat IPs

This enables the firewall/mangle tables rules to ACCEPT instead of RETURN, 
which
is the same behaviour as observed in ACS 4.5. By accepting the traffic, 
guest
VMs will be able to communicate tcp traffic between each other over snat 
public
IPs.

This is a regression from ACS 4.5, observed in ACS 4.9.2.0.
Pinging for review - @PaulAngus @borisstoyanov @DagSonsteboSB 
@abhinandanprateek @DaanHoogland and others

@blueorangutan package

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

$ git pull https://github.com/shapeblue/cloudstack CLOUDSTACK-9838

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

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


commit f4835294869f01def94618f2c206160ccb3b719f
Author: Rohit Yadav 
Date:   2017-04-07T11:44:18Z

CLOUDSTACK-9838: Allow ingress traffic between guest VMs via snat IPs

This enables the firewall/mangle tables rules to ACCEPT instead of RETURN, 
which
is the same behaviour as observed in ACS 4.5. By accepting the traffic, 
guest
VMs will be able to communicate tcp traffic between each other over snat 
public
IPs.

Signed-off-by: Rohit Yadav 




> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



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

[jira] [Commented] (CLOUDSTACK-9864) cleanup stale worker VMs after job expiry time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9864:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2030
  
@blueorangutan package


> cleanup stale worker VMs after job expiry time
> --
>
> Key: CLOUDSTACK-9864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9864
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>  Labels: vmware, vsphere, workers
>
> In the present code cleaning worker vms after a timeout is disabled, with the 
> documented reason that there is no API to query for related tasks in vcenter. 
> ACS has an expiry time for jobs and a cancel time for jobs.
> - Jobs that take longer then the expiry time will have their results be be 
> neglected.
> - Jobs that are cancelled are forcibly removed after the cancellation expity 
> time.
> Any worker remaining after expiry+cancellation will surely be stale and can 
> be removed.
> As some administrators may not want this behaviour there will be a setting 
> which by default is false that will guard against cleaning stale worker VMs.
> Stale worker VMs will be cleaned after 2 * (expiry-time + cancellation-time) 
> as a safe margin.
> related settings:
> job.expire.minutes: 1440
> job.cancel.threshold.minutes: 60
> vmware.clean.old.worker.vms: false (new)



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
@blueorangutan test ubuntu kvm-ubuntu


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

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


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

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


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user blueorangutan commented on the issue:

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


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1950
  
@ustcweizhou I've fixed and ported the patch for 4.9 here: 
https://github.com/apache/cloudstack/pull/2033
Let's work on that PR?


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
@blueorangutan package


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
I've checked this on Trillian, LGTM. While I've ports this PR, the work is 
by @ustcweizhou 
Pinging for review -- @wido @ustcweizhou @abhinandanprateek @DaanHoogland 
@karuturi 


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9783) Improve metrics view performance

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9783:


Github user DaanHoogland commented on the issue:

https://github.com/apache/cloudstack/pull/2032
  
LGTM, checked the source
$ grep -r 4.9.3.0
no hits


> Improve metrics view performance
> 
>
> Key: CLOUDSTACK-9783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0, 4.9.3.0
>
>
> Metrics view is a pure frontend feature, where several API calls are made to 
> generate the metrics view tabular data. In very large environments, rendering 
> of these tables can take a lot of time, especially when there is high 
> latency. The improvement task is to reimplement this feature by moving the 
> logic to backend so metrics calculations happen at the backend and final 
> result can be served by a single API request.



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

[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9099:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1996
  
@jayapalu can you push -f to kick Travis?


> SecretKey is returned from the APIs
> ---
>
> Key: CLOUDSTACK-9099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
> Fix For: 4.10.0.0, 4.9.3.0
>
>
> The sercreKey parameter is returned from the following APIs:
> createAccount
> createUser
> disableAccount
> disableUser
> enableAccount
> enableUser
> listAccounts
> listUsers
> lockAccount
> lockUser
> registerUserKeys
> updateAccount
> updateUser



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

[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9099:


Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/1996
  
It seems there is issue in CI due to that test are failing. 


> SecretKey is returned from the APIs
> ---
>
> Key: CLOUDSTACK-9099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
> Fix For: 4.10.0.0, 4.9.3.0
>
>
> The sercreKey parameter is returned from the following APIs:
> createAccount
> createUser
> disableAccount
> disableUser
> enableAccount
> enableUser
> listAccounts
> listUsers
> lockAccount
> lockUser
> registerUserKeys
> updateAccount
> updateUser



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1950
  
@ustcweizhou can you apply this change:

diff --git a/debian/control b/debian/control
index a019043..460ce7a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Description: A common package which contains files which 
are shared by several C
 
 Package: cloudstack-management
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, openjdk-8-jre-headless | 
java8-runtime-headless | java8-runtime, cloudstack-common (= 
${source:Version}), tomcat6 | tomcat7, sudo, jsvc, python-mysql.connector, 
libmysql-java, augeas-tools, mysql-client, adduser, bzip2, ipmitool, 
lsb-release, init-system-helpers (>= 1.14~)
+Depends: ${python:Depends}, openjdk-8-jre-headless | 
java8-runtime-headless | java8-runtime, cloudstack-common (= 
${source:Version}), tomcat6 | tomcat7, sudo, jsvc, python-mysql.connector, 
libmysql-java, augeas-tools, mysql-client, adduser, bzip2, ipmitool, 
lsb-release, init-system-helpers (>= 1.14~)
 Conflicts: cloud-server, cloud-client, cloud-client-ui



> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9591:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2022
  
@sateesh-chodapuneedi see the JIRA ticket 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591
The exceptions are seen in SSVM logs


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



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

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9591:


Github user sateesh-chodapuneedi commented on the issue:

https://github.com/apache/cloudstack/pull/2022
  
>>Having this causes the ssvms to not deploy in dvswitch-based vmware 
environments that have no vswitch portgroups (dummy etc). 
@rhtyd can you please share the error/log messages for the deployment 
failures?


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1950
  
Failed due to `cloudstack-management : Depends: init-system-helpers (>= 
1.18~) but 1.14 is to be installed`. @ustcweizhou can you explicitly set the 
dependency init-system-helpers (>= 1.14~) for the packages?


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9783) Improve metrics view performance

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9783:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/2032
  
Thanks @karuturi I usually rebuild CloudStack when forward merging PRs to 
ensure they don't break the forward-branches


> Improve metrics view performance
> 
>
> Key: CLOUDSTACK-9783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0, 4.9.3.0
>
>
> Metrics view is a pure frontend feature, where several API calls are made to 
> generate the metrics view tabular data. In very large environments, rendering 
> of these tables can take a lot of time, especially when there is high 
> latency. The improvement task is to reimplement this feature by moving the 
> logic to backend so metrics calculations happen at the backend and final 
> result can be served by a single API request.



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

[jira] [Commented] (CLOUDSTACK-9783) Improve metrics view performance

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9783:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1944
  
@karuturi thanks for fixing it


> Improve metrics view performance
> 
>
> Key: CLOUDSTACK-9783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0, 4.9.3.0
>
>
> Metrics view is a pure frontend feature, where several API calls are made to 
> generate the metrics view tabular data. In very large environments, rendering 
> of these tables can take a lot of time, especially when there is high 
> latency. The improvement task is to reimplement this feature by moving the 
> logic to backend so metrics calculations happen at the backend and final 
> result can be served by a single API request.



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