date:20170213

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user blueorangutan commented on the issue:

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


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user borisstoyanov commented on the issue:

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


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
@karuturi This one is ready for merging. Two LGTMs + tests passing on all 3 
hypervisors


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
Trillian test result (tid-817)
Environment: vmware-60u2 (x2), Advanced Networking with Mgmt server 7
Total time taken: 43428 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1727-t817-vmware-60u2.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_vpc_redundant.py
Test completed. 48 look ok, 1 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 808.93 | 
test_privategw_acl.py
test_01_vpc_site2site_vpn | Success | 321.50 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 161.88 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 538.04 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 289.56 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 721.30 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 627.21 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1478.29 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 638.93 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 608.03 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1310.61 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 20.77 | test_volumes.py
test_06_download_detached_volume | Success | 50.49 | test_volumes.py
test_05_detach_volume | Success | 100.26 | test_volumes.py
test_04_delete_attached_volume | Success | 10.20 | test_volumes.py
test_03_download_attached_volume | Success | 15.30 | test_volumes.py
test_02_attach_volume | Success | 49.58 | test_volumes.py
test_01_create_volume | Success | 435.28 | test_volumes.py
test_change_service_offering_for_vm_with_snapshots | Success | 500.36 | 
test_vm_snapshots.py
test_03_delete_vm_snapshots | Success | 275.21 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 222.12 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 201.53 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 161.64 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 262.85 | 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.95 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 56.05 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.11 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 5.12 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.13 | test_vm_life_cycle.py
test_02_start_vm | Success | 15.20 | test_vm_life_cycle.py
test_01_stop_vm | Success | 5.12 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 206.63 | 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.05 | test_templates.py
test_04_extract_template | Success | 10.23 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.14 | test_templates.py
test_01_create_template | Success | 105.82 | test_templates.py
test_10_destroy_cpvm | Success | 261.82 | test_ssvm.py
test_09_destroy_ssvm | Success | 233.75 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.62 | test_ssvm.py
test_07_reboot_ssvm | Success | 188.54 | test_ssvm.py
test_06_stop_cpvm | Success | 171.74 | test_ssvm.py
test_05_stop_ssvm | Success | 173.73 | test_ssvm.py
test_04_cpvm_internals | Success | 1.17 | test_ssvm.py
test_03_ssvm_internals | Success | 3.28 | 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 | 16.17 | test_snapshots.py
test_04_change_offering_small | Success | 116.84 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py
test_01_create_service_offering | Success |

[jira] [Commented] (CLOUDSTACK-9703) Start VM does not honor cluster.cpu.allocated.capacity.disablethreshold if the vm is startting on last host

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9703:


Github user cloudmonger commented on the issue:

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

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


**Failed tests:**

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

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


> Start VM does not honor cluster.cpu.allocated.capacity.disablethreshold if 
> the vm is startting on last host
> ---
>
> Key: CLOUDSTACK-9703
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9703
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Steps to reproduce:
> 1. Create a xen cluster with multiple instances. Keep some instances in STOP 
> state
> 2. Check the CPU Allocated in Cluster Metrics page. It was 57%
> 3. Set cluster.cpu.allocated.capacity.disablethreshold to 50% and restart 
> cloudstack-management service
> 4. Re-Login the server and goto cluster metrics page again. CPU Allocated 
> field is highlighted in Red
> 5. Start an instance in which was in stopped state.
> 6. CPU allocation increases from 57% to 67%
> Expected:
> If CPU allocated values has already crossed 
> cluster.cpu.allocated.capacity.disablethreshold start VM operation should not 
> be allowed.



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/1939
  
LGTM


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-9717) [VMware] RVRs have mismatching MAC addresses for extra public NICs

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9717:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1878
  
Hi @sureshanaparti 
Would you mind extracting the code at lines 1967-1972 to a specific method? 
Then, it allows you to write test cases for the newly created method and proper 
documentation of the method behaviors?


> [VMware] RVRs have mismatching MAC addresses for extra public NICs
> --
>
> Key: CLOUDSTACK-9717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> [CLOUDSTACK-985|https://issues.apache.org/jira/browse/CLOUDSTACK-985] doesn't 
> seem to be completely fixed.
> ISSUE
> ==
> If there are two public networks on two VLANs, and a pair redundant VRs 
> acquire IPs from both, the associated NICs on the redundant VRs will have 
> mismatching MAC addresses.  
> The example below shows the eth2 NICs for the first public network 
> (210.140.168.0/21) have matching MAC addresses (06:c4:b6:00:03:df) as 
> expected, but the eth3 NICs for the second one (210.140.160.0/21) have 
> mismatching MACs (02:00:50:e1:6c:cd versus 02:00:5a:e6:6c:d5).
> *r-43584-VM (Master)*
> 6: eth2:  mtu 1500 qdisc mq state UNKNOWN 
> qlen 1000 
> link/ether 06:c4:b6:00:03:df brd ff:ff:ff:ff:ff:ff 
> inet 210.140.168.42/21 brd 210.140.175.255 scope global eth2 
> inet 210.140.168.20/21 brd 210.140.175.255 scope global secondary eth2 
> 8: eth3:  mtu 1500 qdisc mq state UNKNOWN 
> qlen 1000 
> link/ether 02:00:50:e1:6c:cd brd ff:ff:ff:ff:ff:ff 
> inet 210.140.162.124/21 brd 210.140.167.255 scope global eth3 
> inet 210.140.163.36/21 brd 210.140.167.255 scope global secondary eth3 
> *r-43585-VM (Backup)*
> 6: eth2:  mtu 1500 qdisc noop state DOWN qlen 1000 
> link/ether 06:c4:b6:00:03:df brd ff:ff:ff:ff:ff:ff 
> inet 210.140.168.42/21 brd 210.140.175.255 scope global eth2 
> inet 210.140.168.20/21 brd 210.140.175.255 scope global secondary eth2 
> 8: eth3:  mtu 1500 qdisc noop state DOWN qlen 1000 
> link/ether 02:00:5a:e6:6c:d5 brd ff:ff:ff:ff:ff:ff 
> inet 210.140.162.124/21 brd 210.140.167.255 scope global eth3 
> inet 210.140.163.36/21 brd 210.140.167.255 scope global secondary eth3 
> CloudStack should ensure that the NICs for all public networks have matching 
> MACs.
> REPRO STEPS
> ==
> 1) Set up redundant VR.
> 2) Set up multiple public networks on different VLANs.
> 3) Acquire IPs in the RVR network until the VRs get IPs in the different 
> public networks.
> 4) Confirm the mismatching MAC addresses.
> EXPECTED BEHAVIOR
> ==
> Redundant VRs have matching MACs for all public networks.
> ACTUAL BEHAVIOR
> ==
> Redundant VRs have matching MACs only for the first public network.



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

[jira] [Commented] (CLOUDSTACK-9721) Remove deprecated/unused global configuration parameter - consoleproxy.loadscan.interval

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9721:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1881
  
@sureshanaparti Thanks for the cleanup. LGTM
@sateesh-chodapuneedi this is a good question. The changes here remove an 
attribute of an Enum that is not referenced anywhere. In my opinion, we should 
not need to run function tests.


> Remove deprecated/unused global configuration parameter - 
> consoleproxy.loadscan.interval
> 
>
> Key: CLOUDSTACK-9721
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9721
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> CloudStack doesn't uses "consoleproxy.loadscan.interval" parameter.



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

[jira] [Commented] (CLOUDSTACK-9728) query to traffic sentinel requesting for usage stats is too long resulting in traffic sentinel sending HTTP 414 error response

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9728:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1886
  
@jayapalu you changed the request type to `POST`. Is the server side (the 
bit that will handle/deliver this request) expecting `POST` requests as well?

Also, how do you feel about extracting the request object creation (lines 
214-219) to a specific method? Then, we can document and describe what how the 
method is supposed to work; it also enabled the writing of test cases (for this 
request creation method).



> query to traffic sentinel requesting for usage stats is too long resulting in 
> traffic sentinel sending HTTP 414 error response
> --
>
> Key: CLOUDSTACK-9728
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9728
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> The query sent to the traffic sentinel to retrieve network usage information 
> is rejected with a 414 error because the string is too long for it to process



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

[jira] [Commented] (CLOUDSTACK-9763) vpc: can not ssh to instance after vpc restart

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9763:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1919
  
@serbaut  I would only like to make a few questions to see if I understood 
the issue here, before evaluating the code any further.

When you first deploy the VM, the keys are delivered to the newly deployed 
VM, right? The problem only happens on reboots?

Do we need to always keep sending the same access keys? Is not one time 
enough? Of course, if the keys are changed, we should send them; but otherwise, 
it feels that we should not need to keep sending them.




> vpc: can not ssh to instance after vpc restart
> --
>
> Key: CLOUDSTACK-9763
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9763
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router, VPC
>Affects Versions: 4.8.0
>Reporter: Joakim Sernbrant
>
> Restart with Cleanup of a VPC does not update the public-key metadata, it is 
> explicitly set to null in 
> https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/CommandSetupHelper.java#L614
> Rebooting instances relying on metadata (e.g. coreos) will no longer have the 
> correct public key configured.



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
Great, thanks @borisstoyanov!


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9772) Perform HEAD request to retrieve header information

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9772:


Github user remibergsma commented on the issue:

https://github.com/apache/cloudstack/pull/1934
  
What about signed S3 urls that people may supply? If you want to register a 
template and have it download from a S3 bucket, you need to specify a signed 
url to provide the authentication. But that signature is valid for either GET 
or HEAD requests, not both. 

When you use S3 as secondary storage, you automatically get a GET 
pre-signed url from CloudStack that you cannot use to register it as a new 
template. Something to think about..

See: 
http://stackoverflow.com/questions/15717230/pre-signing-amazon-s3-urls-for-both-head-and-get-verbs
 


> Perform HEAD request to retrieve header information
> ---
>
> Key: CLOUDSTACK-9772
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9772
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 
> 4.4.3, 4.3.2, 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 
> 4.9.0, 4.8.1.1, 4.9.0.1, 4.5.2.2
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> The function in UriUtils which perform a check for the template file size of 
> an arbitrary URL is sending a `GET` request to only retrieve the response 
> header. A `HEAD` is the correct way of retrieving such information from the 
> response header.
> This was affecting the restart of a management server since all templates 
> were retrieved when receiving the startup command from the secondary storage 
> sysvm.



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
@blueorangutan test centos7 vmware-60u2


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

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


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
There you go @nvazquez, results should come up in 6-8 hours.


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
Thanks @borisstoyanov! Can we test it against Vmware?


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9772) Perform HEAD request to retrieve header information

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9772:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1934
  
Trillian test result (tid-815)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 27420 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1934-t815-kvm-centos7.zip
Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
Test completed. 48 look ok, 1 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 315.33 | 
test_privategw_acl.py
test_01_vpc_site2site_vpn | Success | 160.02 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 61.36 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 230.58 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 269.92 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 533.06 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 485.65 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1413.44 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 538.62 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 734.57 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1290.28 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 151.53 | test_volumes.py
test_08_resize_volume | Success | 156.46 | test_volumes.py
test_07_resize_fail | Success | 161.45 | test_volumes.py
test_06_download_detached_volume | Success | 156.32 | test_volumes.py
test_05_detach_volume | Success | 150.78 | test_volumes.py
test_04_delete_attached_volume | Success | 151.31 | test_volumes.py
test_03_download_attached_volume | Success | 156.32 | test_volumes.py
test_02_attach_volume | Success | 89.12 | test_volumes.py
test_01_create_volume | Success | 621.05 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.21 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 100.83 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 133.77 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 282.86 | 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.66 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.31 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 35.88 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 130.85 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.84 | test_vm_life_cycle.py
test_02_start_vm | Success | 5.13 | test_vm_life_cycle.py
test_01_stop_vm | Success | 35.31 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 60.61 | 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 | 5.14 | test_templates.py
test_03_delete_template | Success | 5.10 | test_templates.py
test_02_edit_template | Success | 90.20 | test_templates.py
test_01_create_template | Success | 65.56 | test_templates.py
test_10_destroy_cpvm | Success | 161.62 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.23 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.34 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.78 | test_ssvm.py
test_06_stop_cpvm | Success | 131.50 | test_ssvm.py
test_05_stop_ssvm | Success | 133.61 | test_ssvm.py
test_04_cpvm_internals | Success | 0.98 | test_ssvm.py
test_03_ssvm_internals | Success | 3.38 | 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.48 | test_snapshots.py
test_04_change_offering_small | Success | 209.62 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.05 | test_service_offerings.py
test_01_create_service_offering | Success | 0.11 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.15 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py
test_09_reboot_router |

[jira] [Commented] (CLOUDSTACK-9655) The template which is registered in all zones will be deleted by deleting 1 template on any zone

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9655:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1818
  
related to this PR, I doubt the action in deleteTemplate on UI (from a 
zone).
```
 if 
(!args.context.templates[0].crossZones){
queryParams += 
"=" + args.context.zones[0].zoneid;
 }
```
should "!" is removed in the first line ?

I would suggest to add the new button in the template details page, and use 
this warning message ("message.action.delete.template.for.all.zones").




> The template which is registered in all zones will be deleted by deleting 1 
> template on any zone
> 
>
> Key: CLOUDSTACK-9655
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9655
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> for a crosszone template, trying to delete a copy of it in one zone will 
> delete it from all the zones without showing any warning in UI.



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

[jira] [Commented] (CLOUDSTACK-9724) VPC tier network restart with cleanup, missing public ip on VR interface

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9724:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1885
  
The issue can be reproduced and fixed by this PR.
LGTM


> VPC tier network restart with cleanup, missing public ip on VR interface
> 
>
> Key: CLOUDSTACK-9724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9724
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> On vpc tier network restart with clean up missing secondary ip addresses on 
> the VR public interface.
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1939
  
code LGTM


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1939
  
```
[INFO] Apache CloudStack Plugin - F5 . SUCCESS [2.778s]
[INFO] Apache CloudStack Plugin - Juniper SRX  FAILURE [0.107s]
[INFO] Apache CloudStack VMware Base . SKIPPED

[INFO] 

[ERROR] Failed to execute goal on project cloud-plugin-network-srx: Could 
not resolve dependencies for project 
org.apache.cloudstack:cloud-plugin-network-srx:jar:4.10.0.0-SNAPSHOT: Could not 
find artifact com.cloud.com.f5:icontrol:jar:1.0 in central 
(https://repo.maven.apache.org/maven2) -> [Help 1]
```
@jayapalu looks like some dependency is missing


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8950:
-

Commit 3c28ce7f4d84c9fbb3b3d054a8cc8df619d5edae in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3c28ce7 ]

Merge pull request #928 from karuturi/CLOUDSTACK-8950

CLOUDSTACK-8950 Hypervisor Parameter check is not performed for 
registerTemplate and getUploadParamsForTemplate API'sAny string is allowed as 
hypervisor type from the api.
HypervisorType.getType() tries to validates with the enums and if nothing
matches sets the type as None.

Added a check to not allow None hypervisor type when registering.

will update test results and testing done later.

* pr/928:
  CLOUDSTACK-8950 Hypervisor Parameter check is not performed for 
registerTemplate and getUploadParamsForTemplate API's

Signed-off-by: Rajani Karuturi 


> Hypervisor Parameter check is not performed  for registerTemplate and 
> getUploadParamsForTemplate API's.
> ---
>
> Key: CLOUDSTACK-8950
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.7.2, Future
>
>
> Register Template : 
> http://10.220.135.31:8096/client/api?command=registerTemplate=urlapi=VHD=ABC=urlapi1=6c590b5c-fde9-11e4-b65a-a20b7b72c771=http://10.147.28.7/templates/rajani-thin-volume.vhd=1e7bbab9-02cd-4067-99f9-3f8b115304df
> getUploadParamsForTemplate : 
> http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate=template=json=nossvm=nossvmnossvm=ca8adf51-539d-45eb-b205-792a58503d14=VHD=false=false=false=ce099056-ee53-11e4-a8ad-d242118f6f9b=XEN=false=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg=admin=cddff412-ee53-11e4-a8ad-d242118f6f9b
> In the above API calls have given the hypervisor types as ABC and XEN 
> respectively. No error is thrown and templates are sucessfully registerd and 
> Uploaded . But they do not list in the Templates section as DB entry for the 
> above shows HYpervisor as NONE . 
> Expected Result : 
> Hypervisor parameter should only accept values which the cloudstack currently 
> supports and API should fail if we give any other values . Templates should 
> not be uploaded for NONE type .



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

[jira] [Commented] (CLOUDSTACK-9772) Perform HEAD request to retrieve header information

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9772:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1934
  
OK @marcaurele, if you're 100% sure it works as expected it could be that 
we need to redesign the test itself, I guess it needs deeper investigation of 
the failure itself. 
@blueorangutan test


> Perform HEAD request to retrieve header information
> ---
>
> Key: CLOUDSTACK-9772
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9772
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 
> 4.4.3, 4.3.2, 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 
> 4.9.0, 4.8.1.1, 4.9.0.1, 4.5.2.2
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> The function in UriUtils which perform a check for the template file size of 
> an arbitrary URL is sending a `GET` request to only retrieve the response 
> header. A `HEAD` is the correct way of retrieving such information from the 
> response header.
> This was affecting the restart of a management server since all templates 
> were retrieved when receiving the startup command from the secondary storage 
> sysvm.



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

[jira] [Commented] (CLOUDSTACK-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8950:
-

Commit cc06c5189a377fc6bc4b7e8bbed56e9058588863 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cc06c51 ]

CLOUDSTACK-8950 Hypervisor Parameter check is not performed for
registerTemplate and getUploadParamsForTemplate API's

Any string is allowed as hypervisor type from the api.
HypervisorType.getType() tries to validate with the enums and if nothing
matches, sets the type as None.

Added a check to not allow None hypervisor type when registering.


> Hypervisor Parameter check is not performed  for registerTemplate and 
> getUploadParamsForTemplate API's.
> ---
>
> Key: CLOUDSTACK-8950
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.7.2, Future
>
>
> Register Template : 
> http://10.220.135.31:8096/client/api?command=registerTemplate=urlapi=VHD=ABC=urlapi1=6c590b5c-fde9-11e4-b65a-a20b7b72c771=http://10.147.28.7/templates/rajani-thin-volume.vhd=1e7bbab9-02cd-4067-99f9-3f8b115304df
> getUploadParamsForTemplate : 
> http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate=template=json=nossvm=nossvmnossvm=ca8adf51-539d-45eb-b205-792a58503d14=VHD=false=false=false=ce099056-ee53-11e4-a8ad-d242118f6f9b=XEN=false=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg=admin=cddff412-ee53-11e4-a8ad-d242118f6f9b
> In the above API calls have given the hypervisor types as ABC and XEN 
> respectively. No error is thrown and templates are sucessfully registerd and 
> Uploaded . But they do not list in the Templates section as DB entry for the 
> above shows HYpervisor as NONE . 
> Expected Result : 
> Hypervisor parameter should only accept values which the cloudstack currently 
> supports and API should fail if we give any other values . Templates should 
> not be uploaded for NONE type .



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

[jira] [Commented] (CLOUDSTACK-9117) Add marvin test to verify adding some TCP ports in vpn won't fail

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-9117:
-

Commit 8efdcfc1cdbda9d0a90c701e83a525c64d613e03 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8efdcfc ]

Merge pull request #1183 from sanju1010/tcpports

Marvin test to verify that adding TCP ports 500,4500 and 1701 in vpn should not 
failPlease refer to JIRA ticket for more details
https://issues.apache.org/jira/browse/CLOUDSTACK-9117

Following is the result info:
Test to add TCP Port Forwarding rule for specific ports(500,1701 and 4500) in 
VPN ... === TestName: test_08_add_TCP_PF_Rule_In_VPN | Status : SUCCESS ===
ok

---

Ran 1 test in 166.799s

OK

* pr/1183:
  Marvin test to verify that adding TCP ports 500,4500 and 1701 in vpn should 
not fail Bug-Id: CS-43653 Reviewed-by: Self

Signed-off-by: Rajani Karuturi 


> Add marvin test to verify adding some TCP ports in vpn won't fail
> -
>
> Key: CLOUDSTACK-9117
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9117
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Add marvin test to verify adding some TCP ports in vpn won't fail
> Steps to follow:
> 
> In an advanced zone
> 1.Create Remote access vpn on SourceNAT IP address
> 2.Create PortForwarding rules on the same ip address with TCP ports 500,4500 
> and 1701.
> This is to make sure that VPN ports (UDP ports 500,4500 and 1701) won't give 
> conflict when configuring PF with TCP ports.



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user blueorangutan commented on the issue:

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


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/873
  
added ifdebugenabled() checks 


> Allocated percentage of storage can go beyond 100%
> --
>
> Key: CLOUDSTACK-8896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope 
> primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another 
> cluster, the volume is moved to the new cluster and the asking size is zero 
> at this time.
> you can observe logs like below with asking size 0 in the management server 
> logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] 
> (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) 
> (logid:a0a97129) Checking pool: 1 for volume allocation 
> [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 
> 24096276480, askingSize : 0, allocated disable threshold: 0.85



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

[jira] [Commented] (CLOUDSTACK-9753) Update L10N resource files with 4.10 strings from Transifex (20170121)

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9753:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1914
  
LGTM, /cc @karuturi 


> Update L10N resource files with 4.10 strings from Transifex (20170121)
> --
>
> Key: CLOUDSTACK-9753
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9753
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Assignee: Milamber
>Priority: Minor
> Fix For: 4.10.0.0
>
>




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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user borisstoyanov commented on the issue:

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


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8665) Support for non-US keyboards in Console Proxy

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8665:


GitHub user anshul1886 reopened a pull request:

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

Made the adding new keyboard language support easier

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

This branch has implemented following improvements in console proxy 
keyboard language support

1) ajaxviewer.js and ajaxkeys.js are main files involved in key code 
translations. These files now can be copied in systemvm/js folder and they will 
be copied to CPVM with stop/start performed on it.
2) Started passing parameters to CPVM needed to resolve the ambiguous cases 
of keycode translations.
3) Generalise the framework such that one needs to modify only ajaxkeys.js 
(file which has keycode mappings) without need of much knowledge in js.

FS for this feature is available at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+for+non-US+keyboards+in+Console+Proxy

After these changes how to add keyboard support for new language or fix 
existing broken keys WIP document  is available at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Adding+support+for+non-US+Keyboard+for+Console+Proxy


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

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

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

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


commit 31e12325e715420536ee3215e312474be1b258a5
Author: Anshul Gangwar 
Date:   2015-08-04T04:54:16Z

CLOUDSTACK-8665: Added following improvements:
1. Added support for copying js files from management server to console 
proxy VM with stop start
2. Generalise console keyboard support framework
3. Passing additional parameters which will be needed for keyboard mappings 
for vm console
4. Moved the console Keyboard Options to new file so that user can add 
keyboard options easily
5. Improved memory footprint, now keeping only required locale mappings
6. Added more conditions while setting up translation table
7. Improved browser detection for keyboard mappings
8. Formatted ajaxviewer.js and ajaxkeys.js with spaces instead of tabs




> Support for non-US keyboards in Console Proxy
> -
>
> Key: CLOUDSTACK-8665
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8665
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Make it easier for CloudStack service providers to add their own keyboards



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

[jira] [Commented] (CLOUDSTACK-9780) Default to Java8 if JAVA_HOME is not set

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9780:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1938
  
@borisstoyanov can you post ubuntu test results?


> Default to Java8 if JAVA_HOME is not set
> 
>
> Key: CLOUDSTACK-9780
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9780
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Will Stevens
>
> Now that PR1888 is merged, Java8 is required.  Unfortunately the file pushed 
> to `/etc/cloudstack/management/classpath.conf` will default to Java7 if the 
> JAVA_HOME is not set.  



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

[jira] [Commented] (CLOUDSTACK-9772) Perform HEAD request to retrieve header information

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9772:


Github user blueorangutan commented on the issue:

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


> Perform HEAD request to retrieve header information
> ---
>
> Key: CLOUDSTACK-9772
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9772
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 
> 4.4.3, 4.3.2, 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 
> 4.9.0, 4.8.1.1, 4.9.0.1, 4.5.2.2
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> The function in UriUtils which perform a check for the template file size of 
> an arbitrary URL is sending a `GET` request to only retrieve the response 
> header. A `HEAD` is the correct way of retrieving such information from the 
> response header.
> This was affecting the restart of a management server since all templates 
> were retrieved when receiving the startup command from the secondary storage 
> sysvm.



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

[jira] [Commented] (CLOUDSTACK-8665) Support for non-US keyboards in Console Proxy

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8665:


Github user anshul1886 closed the pull request at:

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


> Support for non-US keyboards in Console Proxy
> -
>
> Key: CLOUDSTACK-8665
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8665
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Make it easier for CloudStack service providers to add their own keyboards



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

[jira] [Commented] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-9715:
-

Commit dbb2193641cfee18a74082a7697dbcc4e2f20892 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dbb2193 ]

Merge pull request #1876 from Accelerite/somaxconn

CLOUDSTACK-9715: Update somaxconn value to default valueUpdated the somaxconn 
value to detault value 65535

* pr/1876:
  CLOUDSTACK-9715: Update somaxconn value to default value

Signed-off-by: Rajani Karuturi 


> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



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

[jira] [Commented] (CLOUDSTACK-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8950:


Github user asfgit closed the pull request at:

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


> Hypervisor Parameter check is not performed  for registerTemplate and 
> getUploadParamsForTemplate API's.
> ---
>
> Key: CLOUDSTACK-8950
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.7.2, Future
>
>
> Register Template : 
> http://10.220.135.31:8096/client/api?command=registerTemplate=urlapi=VHD=ABC=urlapi1=6c590b5c-fde9-11e4-b65a-a20b7b72c771=http://10.147.28.7/templates/rajani-thin-volume.vhd=1e7bbab9-02cd-4067-99f9-3f8b115304df
> getUploadParamsForTemplate : 
> http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate=template=json=nossvm=nossvmnossvm=ca8adf51-539d-45eb-b205-792a58503d14=VHD=false=false=false=ce099056-ee53-11e4-a8ad-d242118f6f9b=XEN=false=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg=admin=cddff412-ee53-11e4-a8ad-d242118f6f9b
> In the above API calls have given the hypervisor types as ABC and XEN 
> respectively. No error is thrown and templates are sucessfully registerd and 
> Uploaded . But they do not list in the Templates section as DB entry for the 
> above shows HYpervisor as NONE . 
> Expected Result : 
> Hypervisor parameter should only accept values which the cloudstack currently 
> supports and API should fail if we give any other values . Templates should 
> not be uploaded for NONE type .



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

[jira] [Commented] (CLOUDSTACK-9724) VPC tier network restart with cleanup, missing public ip on VR interface

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9724:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1885#discussion_r100767709
  
--- Diff: server/src/com/cloud/network/IpAddressManagerImpl.java ---
@@ -460,6 +460,12 @@ boolean checkIfIpAssocRequired(Network network, 
boolean postApplyRules, List 0) {
+if (network.getVpcId() != null) {
--- End diff --

@jayapalu Please improve the code comment


> VPC tier network restart with cleanup, missing public ip on VR interface
> 
>
> Key: CLOUDSTACK-9724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9724
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> On vpc tier network restart with clean up missing secondary ip addresses on 
> the VR public interface.
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



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

[jira] [Commented] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-9715:
-

Commit 45c3d94d83cc70a80f493f2de62406853f06d6ac in cloudstack's branch 
refs/heads/master from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=45c3d94 ]

CLOUDSTACK-9715: Update somaxconn value to default value


> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



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

[jira] [Commented] (CLOUDSTACK-9691) unhandeled excetion in list snapshot command when a primary store is deleted

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9691:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1847
  
@anshul1886 can you and @nvazquez work together and create a single PR?


> unhandeled excetion in list snapshot command when a primary store is deleted
> 
>
> Key: CLOUDSTACK-9691
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9691
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>
> Repro steps:
> I have a setup with 3 clusters . for one cluster i deleted the primary storage
> now when i traverse to storage tab getting exception "Unable to locate 
> datastore with id 1"
> DB entries for deleted primary storage :
> "id"  "name"  "uuid"  "pool_type" "port"  "data_center_id"
> "pod_id""cluster_id" "used_bytes"   "capacity_bytes"
> "host_address"  "user_info" "path"  "created" "removed" "update_time" 
>   "status""storage_provider_name" "scope" "hypervisor" "managed"  
> "capacity_iops"
> "1"   ""  \N  "NetworkFilesystem" "2049"  "1" "1" "1" 
> "4674624913408" "5902284816384" "10.147.28.7"   \N  
> "/export/home/shweta/471.xen.primary"   "2016-08-17 08:14:12"   "2016-08-25 
> 04:54:53"   \N  "Maintenance"   "DefaultPrimary" "CLUSTER"  \N  
> "0" \N
> MS log shows :
> 2016-08-26 14:34:36,709 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-1:ctx-90c9ba3a) (logid:115e39ad) ===START=== 10.233.88.59 – 
> GET 
> command=listSnapshots=json=true=1=20&_=1472202277072
> 2016-08-26 14:34:36,747 ERROR [c.c.a.ApiServer] (catalina-exec-1:ctx-90c9ba3a 
> ctx-94284178) (logid:115e39ad) unhandled exception executing api command: 
> [Ljava.lang.String;@77f27ce8
> com.cloud.utils.exception.CloudRuntimeException: Unable to locate datastore 
> with id 1
> at 
> org.apache.cloudstack.storage.datastore.manager.PrimaryDataStoreProviderManagerImpl.getPrimaryDataStore(PrimaryDataStoreProviderManagerImpl.java:61)
> at 
> org.apache.cloudstack.storage.datastore.DataStoreManagerImpl.getDataStore(DataStoreManagerImpl.java:48)
> at 
> com.cloud.api.ApiResponseHelper.getDataStoreRole(ApiResponseHelper.java:571)
> at 
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:537)
> at 
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:117)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:707)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:538)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:297)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at 
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
> at 
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
>

[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8717:
-

Commit a79c1f6722efde9dbefe856c09c07b9cc31a06ae in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a79c1f6 ]

Merge pull request #1416 from 
pritisarap12/CLOUDSTACK-8717-Failed-to-start-instance-after-restoring-the-running-instance

CLOUDSTACK-8717: Failed to start instance after restoring the running instance 
Changing PR title and commit message
In continuation with PR #1411  and  #667

* pr/1416:
  CLOUDSTACK-8717: Failed to start instance after restoring the running instance

Signed-off-by: Rajani Karuturi 


> Failed to start instance after restoring the running instance 
> --
>
> Key: CLOUDSTACK-8717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> On setup with two cluster wide primary storage verify restoring a running 
> instance.(As while restoring instance root disk may get created on another 
> primary storage.) 



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/858
  
created new #PR 1939 for this PR.


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8950:
-

Commit 3c28ce7f4d84c9fbb3b3d054a8cc8df619d5edae in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3c28ce7 ]

Merge pull request #928 from karuturi/CLOUDSTACK-8950

CLOUDSTACK-8950 Hypervisor Parameter check is not performed for 
registerTemplate and getUploadParamsForTemplate API'sAny string is allowed as 
hypervisor type from the api.
HypervisorType.getType() tries to validates with the enums and if nothing
matches sets the type as None.

Added a check to not allow None hypervisor type when registering.

will update test results and testing done later.

* pr/928:
  CLOUDSTACK-8950 Hypervisor Parameter check is not performed for 
registerTemplate and getUploadParamsForTemplate API's

Signed-off-by: Rajani Karuturi 


> Hypervisor Parameter check is not performed  for registerTemplate and 
> getUploadParamsForTemplate API's.
> ---
>
> Key: CLOUDSTACK-8950
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.7.2, Future
>
>
> Register Template : 
> http://10.220.135.31:8096/client/api?command=registerTemplate=urlapi=VHD=ABC=urlapi1=6c590b5c-fde9-11e4-b65a-a20b7b72c771=http://10.147.28.7/templates/rajani-thin-volume.vhd=1e7bbab9-02cd-4067-99f9-3f8b115304df
> getUploadParamsForTemplate : 
> http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate=template=json=nossvm=nossvmnossvm=ca8adf51-539d-45eb-b205-792a58503d14=VHD=false=false=false=ce099056-ee53-11e4-a8ad-d242118f6f9b=XEN=false=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg=admin=cddff412-ee53-11e4-a8ad-d242118f6f9b
> In the above API calls have given the hypervisor types as ABC and XEN 
> respectively. No error is thrown and templates are sucessfully registerd and 
> Uploaded . But they do not list in the Templates section as DB entry for the 
> above shows HYpervisor as NONE . 
> Expected Result : 
> Hypervisor parameter should only accept values which the cloudstack currently 
> supports and API should fail if we give any other values . Templates should 
> not be uploaded for NONE type .



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

[jira] [Commented] (CLOUDSTACK-9117) Add marvin test to verify adding some TCP ports in vpn won't fail

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9117:


Github user asfgit closed the pull request at:

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


> Add marvin test to verify adding some TCP ports in vpn won't fail
> -
>
> Key: CLOUDSTACK-9117
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9117
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Add marvin test to verify adding some TCP ports in vpn won't fail
> Steps to follow:
> 
> In an advanced zone
> 1.Create Remote access vpn on SourceNAT IP address
> 2.Create PortForwarding rules on the same ip address with TCP ports 500,4500 
> and 1701.
> This is to make sure that VPN ports (UDP ports 500,4500 and 1701) won't give 
> conflict when configuring PF with TCP ports.



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

[jira] [Commented] (CLOUDSTACK-9724) VPC tier network restart with cleanup, missing public ip on VR interface

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9724:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1885
  
Code changes LGTM


> VPC tier network restart with cleanup, missing public ip on VR interface
> 
>
> Key: CLOUDSTACK-9724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9724
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> On vpc tier network restart with clean up missing secondary ip addresses on 
> the VR public interface.
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


GitHub user jayapalu opened a pull request:

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

CLOUDSTACK-8886: Limitations is listUsageRecords output, listUsageRec…

As @kansal  is inactive created new branch and raised the PR. This is 
continuation of PR#858
https://github.com/apache/cloudstack/pull/858

Problem: Only domainid is returned by usageReports API call. In cloudstack 
documention it mentions "domain" as being in the usage response. The API should 
really be returning the domain as account information has both account and 
accountid.

Fix: Missing setDomainName at the time of creating response.

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

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

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

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


commit f17d27dd93e7c1b0ba60afdf78276a8b07c4dff0
Author: Kshitij Kansal 
Date:   2015-09-21T06:18:17Z

CLOUDSTACK-8886: Limitations is listUsageRecords output, listUsageRecords 
does not return domain - Fixed and tests added




> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-9655) The template which is registered in all zones will be deleted by deleting 1 template on any zone

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9655:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1818
  
LGTM.


> The template which is registered in all zones will be deleted by deleting 1 
> template on any zone
> 
>
> Key: CLOUDSTACK-9655
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9655
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> for a crosszone template, trying to delete a copy of it in one zone will 
> delete it from all the zones without showing any warning in UI.



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

[jira] [Commented] (CLOUDSTACK-9780) Default to Java8 if JAVA_HOME is not set

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9780:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1938
  
@karuturi unfortunately we've hit an issue with the ubuntu images, didn't 
manage to deploy the Trillian env.. 


> Default to Java8 if JAVA_HOME is not set
> 
>
> Key: CLOUDSTACK-9780
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9780
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Will Stevens
>
> Now that PR1888 is merged, Java8 is required.  Unfortunately the file pushed 
> to `/etc/cloudstack/management/classpath.conf` will default to Java7 if the 
> JAVA_HOME is not set.  



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

[jira] [Commented] (CLOUDSTACK-9655) The template which is registered in all zones will be deleted by deleting 1 template on any zone

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9655:


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

https://github.com/apache/cloudstack/pull/1818#discussion_r100771599
  
--- Diff: ui/scripts/templates.js ---
@@ -1447,7 +1447,11 @@
  label: 
'label.action.delete.template',
  messages: {
  confirm: 
function(args) {
- return 
'message.action.delete.template';
+ 
if(args.context.templates[0].crossZones == true) {
+ return 'This 
is a cross zone template and will be deleted from all the zones. Are you sure 
you want to proceed?';
--- End diff --

used an existing message from properties


> The template which is registered in all zones will be deleted by deleting 1 
> template on any zone
> 
>
> Key: CLOUDSTACK-9655
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9655
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> for a crosszone template, trying to delete a copy of it in one zone will 
> delete it from all the zones without showing any warning in UI.



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

[jira] [Commented] (CLOUDSTACK-9780) Default to Java8 if JAVA_HOME is not set

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9780:


Github user asfgit closed the pull request at:

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


> Default to Java8 if JAVA_HOME is not set
> 
>
> Key: CLOUDSTACK-9780
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9780
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Will Stevens
>
> Now that PR1888 is merged, Java8 is required.  Unfortunately the file pushed 
> to `/etc/cloudstack/management/classpath.conf` will default to Java7 if the 
> JAVA_HOME is not set.  



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

[jira] [Commented] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9715:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1876
  
merging. simple config change.


> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



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

[jira] [Commented] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9715:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1876
  
travis failure not related. merging


> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



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

[jira] [Commented] (CLOUDSTACK-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8950:
-

Commit 3c28ce7f4d84c9fbb3b3d054a8cc8df619d5edae in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3c28ce7 ]

Merge pull request #928 from karuturi/CLOUDSTACK-8950

CLOUDSTACK-8950 Hypervisor Parameter check is not performed for 
registerTemplate and getUploadParamsForTemplate API'sAny string is allowed as 
hypervisor type from the api.
HypervisorType.getType() tries to validates with the enums and if nothing
matches sets the type as None.

Added a check to not allow None hypervisor type when registering.

will update test results and testing done later.

* pr/928:
  CLOUDSTACK-8950 Hypervisor Parameter check is not performed for 
registerTemplate and getUploadParamsForTemplate API's

Signed-off-by: Rajani Karuturi 


> Hypervisor Parameter check is not performed  for registerTemplate and 
> getUploadParamsForTemplate API's.
> ---
>
> Key: CLOUDSTACK-8950
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.7.2, Future
>
>
> Register Template : 
> http://10.220.135.31:8096/client/api?command=registerTemplate=urlapi=VHD=ABC=urlapi1=6c590b5c-fde9-11e4-b65a-a20b7b72c771=http://10.147.28.7/templates/rajani-thin-volume.vhd=1e7bbab9-02cd-4067-99f9-3f8b115304df
> getUploadParamsForTemplate : 
> http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate=template=json=nossvm=nossvmnossvm=ca8adf51-539d-45eb-b205-792a58503d14=VHD=false=false=false=ce099056-ee53-11e4-a8ad-d242118f6f9b=XEN=false=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg=admin=cddff412-ee53-11e4-a8ad-d242118f6f9b
> In the above API calls have given the hypervisor types as ABC and XEN 
> respectively. No error is thrown and templates are sucessfully registerd and 
> Uploaded . But they do not list in the Templates section as DB entry for the 
> above shows HYpervisor as NONE . 
> Expected Result : 
> Hypervisor parameter should only accept values which the cloudstack currently 
> supports and API should fail if we give any other values . Templates should 
> not be uploaded for NONE type .



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

[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8886:


Github user blueorangutan commented on the issue:

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


> Limitations is listUsageRecords output - listUsageRecords does not return 
> "domain"
> --
>
> Key: CLOUDSTACK-8886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> Only domainid is returned by usageReports API call.
> In cloudstack documention it mentions "domain" as being in the usage 
> response. The API should really be returning the domain as account 
> information has both account and accountid.



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

[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8717:
-

Commit 06289da022e264c3135413cdb064a414a35e1c8c in cloudstack's branch 
refs/heads/master from [~pritisarap12]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06289da ]

CLOUDSTACK-8717: Failed to start instance after restoring the running instance


> Failed to start instance after restoring the running instance 
> --
>
> Key: CLOUDSTACK-8717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> On setup with two cluster wide primary storage verify restoring a running 
> instance.(As while restoring instance root disk may get created on another 
> primary storage.) 



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

[jira] [Commented] (CLOUDSTACK-9780) Default to Java8 if JAVA_HOME is not set

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9780:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1938
  
good point @swill. Thanks @borisstoyanov.
Since the fix is no different from the earlier version for 1.7, I am 
assuming it should work for 1.8 as well on ubuntu.
merging this now


> Default to Java8 if JAVA_HOME is not set
> 
>
> Key: CLOUDSTACK-9780
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9780
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Will Stevens
>
> Now that PR1888 is merged, Java8 is required.  Unfortunately the file pushed 
> to `/etc/cloudstack/management/classpath.conf` will default to Java7 if the 
> JAVA_HOME is not set.  



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

[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8717:


Github user asfgit closed the pull request at:

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


> Failed to start instance after restoring the running instance 
> --
>
> Key: CLOUDSTACK-8717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> On setup with two cluster wide primary storage verify restoring a running 
> instance.(As while restoring instance root disk may get created on another 
> primary storage.) 



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

[jira] [Commented] (CLOUDSTACK-9699) Metrics: Add a global setting to enable/disable Metrics view

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9699:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1884
  
I'm working on improving the metrics view feature by implementing the logic 
as backend APIs, will post a PR this/next week. Thanks.


> Metrics: Add a global setting to enable/disable Metrics view
> 
>
> Key: CLOUDSTACK-9699
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9699
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.10.0.0
>
> Attachments: enable-metrics-flag.PNG, metrics-disabled.PNG, 
> metrics-enabled.PNG
>
>
> The Metrics view for each type of entity basically fires APIs and calculates 
> required values on the client end. For e.g. to display memory usage etc at 
> the zone level, it will fetch all zones. For each zone it will fetch 
> pods->cluster->host->VMs
> For a very large Cloudstack installation this will have a major impact on the 
> performance. 
> Ideally, there should be an API which calculates all this in the backend and 
> the UI should simply show the values. However, for the time, introduce a 
> global setting called enable.metrics which will be set to false. This will 
> cause the metrics button not to be shown on any of the pages.
> If the Admin changes this to true, then the button will be visible and 
> Metrics functionality will work as usual.



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

[jira] [Commented] (CLOUDSTACK-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-8950:


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

https://github.com/apache/cloudstack/pull/928#discussion_r100753379
  
--- Diff: server/src/com/cloud/template/TemplateAdapterBase.java ---
@@ -293,9 +298,15 @@ public TemplateProfile 
prepare(GetUploadParamsForTemplateCmd cmd) throws Resourc
 zoneId = -1L;
 }
 
+HypervisorType hypervisorType = 
HypervisorType.getType(cmd.getHypervisor());
+if(hypervisorType == HypervisorType.None) {
+throw new InvalidParameterValueException("Hypervisor Type: " + 
cmd.getHypervisor() + " is invalid. Supported Hypervisor types are "
+ + 
EnumUtils.listValues(HypervisorType.values()).replace("None, ", ""));
+}
--- End diff --

@GabrielBrascher there is lot of duplicate code between the methods. A 
proper cleanup has to be planned. Cant take up now.


> Hypervisor Parameter check is not performed  for registerTemplate and 
> getUploadParamsForTemplate API's.
> ---
>
> Key: CLOUDSTACK-8950
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
> Fix For: 4.7.2, Future
>
>
> Register Template : 
> http://10.220.135.31:8096/client/api?command=registerTemplate=urlapi=VHD=ABC=urlapi1=6c590b5c-fde9-11e4-b65a-a20b7b72c771=http://10.147.28.7/templates/rajani-thin-volume.vhd=1e7bbab9-02cd-4067-99f9-3f8b115304df
> getUploadParamsForTemplate : 
> http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate=template=json=nossvm=nossvmnossvm=ca8adf51-539d-45eb-b205-792a58503d14=VHD=false=false=false=ce099056-ee53-11e4-a8ad-d242118f6f9b=XEN=false=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg=admin=cddff412-ee53-11e4-a8ad-d242118f6f9b
> In the above API calls have given the hypervisor types as ABC and XEN 
> respectively. No error is thrown and templates are sucessfully registerd and 
> Uploaded . But they do not list in the Templates section as DB entry for the 
> above shows HYpervisor as NONE . 
> Expected Result : 
> Hypervisor parameter should only accept values which the cloudstack currently 
> supports and API should fail if we give any other values . Templates should 
> not be uploaded for NONE type .



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

[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8717:
-

Commit a79c1f6722efde9dbefe856c09c07b9cc31a06ae in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a79c1f6 ]

Merge pull request #1416 from 
pritisarap12/CLOUDSTACK-8717-Failed-to-start-instance-after-restoring-the-running-instance

CLOUDSTACK-8717: Failed to start instance after restoring the running instance 
Changing PR title and commit message
In continuation with PR #1411  and  #667

* pr/1416:
  CLOUDSTACK-8717: Failed to start instance after restoring the running instance

Signed-off-by: Rajani Karuturi 


> Failed to start instance after restoring the running instance 
> --
>
> Key: CLOUDSTACK-8717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> On setup with two cluster wide primary storage verify restoring a running 
> instance.(As while restoring instance root disk may get created on another 
> primary storage.) 



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

[jira] [Created] (CLOUDSTACK-9781) CCP records ID in events tables instead of UUID.

2017-02-13 Thread Jayant Patil (JIRA)

Jayant Patil created CLOUDSTACK-9781:


 Summary: CCP records ID in events tables instead of UUID.
 Key: CLOUDSTACK-9781
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayant Patil


ISSUE
=
Wrong presentation of volume id in CCP events.
While creating a snapshot, only volume ID is mentioned in the events. For 
example, “Scheduled async job for creating snapshot for volume Id:270". On 
looking into the notification, user is not able to identify the volume. So 
modified event description with UUID.



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

[jira] [Commented] (CLOUDSTACK-9697) Better error message user if tries to shrink the VM ROOT volume size

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9697:


Github user sadhugit commented on the issue:

https://github.com/apache/cloudstack/pull/1855
  
tested on my setup and Looks good to me.
Need to handle on API side  so please update the Bug description  by adding 
UI only


> Better error message user if tries to shrink the VM ROOT volume size
> 
>
> Key: CLOUDSTACK-9697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9697
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> If a user tries to shrink the size of the root volume of a VM, the operation 
> fails with an error 
> Going from existing size of 10737418240 to size of 8589934592 would shrink 
> the volume.Need to sign off by supplying the shrinkok parameter with value of 
> true.
> Instead, the UI can simply not allow shrink operation on the ROOT volume. 
> Throw a more user friendly message
> "Shrink operation on ROOT volume not supported"



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

[jira] [Commented] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9715:


Github user asfgit closed the pull request at:

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


> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



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

[jira] [Commented] (CLOUDSTACK-9780) Default to Java8 if JAVA_HOME is not set

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-9780:
-

Commit da66b06e7d562393da2e4b52206943f8bad49d10 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=da66b06 ]

Merge pull request #1938 from swill/classpath

CLOUDSTACK-9780: Fixed the default JAVA_HOME value to be Java8 if not setNow 
that PR-1888 is merged, Java8 is required.  Unfortunately, the file pushed to 
`/etc/cloudstack/management/classpath.conf` on ACS install will default the 
version to Java7 instead of Java8 if JAVA_HOME is unset.  This fix sets the 
default to Java8 if JAVA_HOME is not set.

* pr/1938:
  Fixed the default JAVA_HOME value to be Java8 if not set

Signed-off-by: Rajani Karuturi 


> Default to Java8 if JAVA_HOME is not set
> 
>
> Key: CLOUDSTACK-9780
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9780
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Will Stevens
>
> Now that PR1888 is merged, Java8 is required.  Unfortunately the file pushed 
> to `/etc/cloudstack/management/classpath.conf` will default to Java7 if the 
> JAVA_HOME is not set.  



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

[jira] [Commented] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-9715:
-

Commit dbb2193641cfee18a74082a7697dbcc4e2f20892 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dbb2193 ]

Merge pull request #1876 from Accelerite/somaxconn

CLOUDSTACK-9715: Update somaxconn value to default valueUpdated the somaxconn 
value to detault value 65535

* pr/1876:
  CLOUDSTACK-9715: Update somaxconn value to default value

Signed-off-by: Rajani Karuturi 


> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



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

[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance

2017-02-13 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-8717:
-

Commit a79c1f6722efde9dbefe856c09c07b9cc31a06ae in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a79c1f6 ]

Merge pull request #1416 from 
pritisarap12/CLOUDSTACK-8717-Failed-to-start-instance-after-restoring-the-running-instance

CLOUDSTACK-8717: Failed to start instance after restoring the running instance 
Changing PR title and commit message
In continuation with PR #1411  and  #667

* pr/1416:
  CLOUDSTACK-8717: Failed to start instance after restoring the running instance

Signed-off-by: Rajani Karuturi 


> Failed to start instance after restoring the running instance 
> --
>
> Key: CLOUDSTACK-8717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> On setup with two cluster wide primary storage verify restoring a running 
> instance.(As while restoring instance root disk may get created on another 
> primary storage.) 



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

[jira] [Commented] (CLOUDSTACK-9772) Perform HEAD request to retrieve header information

2017-02-13 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9772:


Github user marcaurele commented on the issue:

https://github.com/apache/cloudstack/pull/1934
  
@borisstoyanov Dunno what's wrong with the failed tests. Its' failing at 
https://github.com/apache/cloudstack/blob/master/plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java#L83.
 The log says that the ssvm endpoint was not ready.
Could you try to launch another bueorangutan test suite?

We're running that fix in production since a week and haven't hit a problem 
yet.


> Perform HEAD request to retrieve header information
> ---
>
> Key: CLOUDSTACK-9772
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9772
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 
> 4.4.3, 4.3.2, 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 
> 4.9.0, 4.8.1.1, 4.9.0.1, 4.5.2.2
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> The function in UriUtils which perform a check for the template file size of 
> an arbitrary URL is sending a `GET` request to only retrieve the response 
> header. A `HEAD` is the correct way of retrieving such information from the 
> response header.
> This was affecting the restart of a management server since all templates 
> were retrieved when receiving the startup command from the secondary storage 
> sysvm.



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

65 matches

Mail list logo