[jira] [Commented] (CLOUDSTACK-9389) [Automation ]modifying integration/smoke/test_routers_network_ops.py

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9389:


Github user nitt10prashant commented on the issue:

https://github.com/apache/cloudstack/pull/1563
  
@swill just curious  to know Which guest OS you are using ? Since Cent OS 
template is default in ACS i modified test_data for cent OS.  

Regx should be consider ?
->I Agree with you, will push changes for regx  to make sure it work for 
both ping pattern .

What do you think? Sorry, I don't mean to be combative here, but this is a 
good opertunity for us to review the way we handle OS specific test data.
->Yes this should be  discussed thoroughly and should be documented  
properly


> [Automation ]modifying integration/smoke/test_routers_network_ops.py
> 
>
> Key: CLOUDSTACK-9389
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9389
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
>
> Some test cases were failing due to invalid check_string , proposing 
> following modifications  
> 1-Moving check_string to test_data.py  
> 2-Since ping cmd reply is OS dependent ,for  default templates os type  
> CentOS changing check_string  from "3 packets received" to  "3 received" 
> [root@BPKxDmS ~]# ping -c 3 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=16.9 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=16.7 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=17.0 ms
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2020ms
> rtt min/avg/max/mdev = 16.720/16.896/17.015/0.196 ms



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


[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-8908:


Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/896
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 173
 Hypervisor xenserver
 NetworkType Advanced
 Passed=73
 Failed=0
 Skipped=3

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


**Failed tests:**

**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_deploy_vgpu_enabled_vm

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


> After copying the template charging for that template is stopped 
> -
>
> Key: CLOUDSTACK-8908
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template, Usage
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> [Repro Steps]
> Register a template in Zone 1 .
>  Copy the template from Zone 1 to Zone 2 .
>  Once copied, deleted the template from Zone 1.
>  Check the charging of the template and found that charging of the template 
> in Zone 2 stopped
> Sample data related to the issue
> mysql> select id,type,state,description,created from event where description 
> like "%4186%" and type like "%template%"; 
> +-+-+---+-+-+
>  
> | id | type | state | description | created | 
> +-+-+---+-+-+
>  
> | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating 
> template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | 
> | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 
> to zone: 1 | 2015-07-22 03:57:32 | 
> | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: 
> 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | 
> | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying 
> template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 
> 04:47:08 | 
> | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 
> 06:46:18 | 
> | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 
> | 2015-07-22 06:46:18 | 
> | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting 
> template. Template Id: 4186 | 2015-07-22 06:46:18 | 
> +-+-+---+-+-+
>  
> You can see that the template of zone3 is not removed. 
> mysql> select * from template_zone_ref where template_id=4186;; 
> +--+-+-+-+-+-+
>  
> | id | zone_id | template_id | created | last_updated | removed | 
> +--+-+-+-+-+-+
>  
> | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | 
> <=Not removed 
> | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 
> 06:46:18 | 
> +--+-+-+-+-+-+
>  
> However, not only Zone1 but also the charging of the template of Zone3 
> stopped. 
> +-+-+-+-+--+---++--+-+
>  
> | id | start_date | end_date | zone_id | description | usage_display | 
> 

[jira] [Commented] (CLOUDSTACK-8921) snapshot_store_ref table should store actual size of back snapshot in secondary storage

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-8921:


Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/899
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 172
 Hypervisor xenserver
 NetworkType Advanced
 Passed=73
 Failed=0
 Skipped=3

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


**Failed tests:**

**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_deploy_vgpu_enabled_vm

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


> snapshot_store_ref table should store actual size of back snapshot in 
> secondary storage
> ---
>
> Key: CLOUDSTACK-8921
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8921
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, Usage
>Affects Versions: 4.5.2
> Environment: Hypervisor: Xen Server
> Hypervisor Version: 6.2 + SP1 
>Reporter: subhash yedugundla
>
> CCP is storing physical-utilisation of the snapshot in physical_size column 
> of the table "snapshot_store_ref". That was fixed as part of 
> https://issues.apache.org/jira/browse/CLOUDSTACK-7842.
> From DB:
> =
> mysql> select * from snapshot_store_ref where id=586 \G;
> id: 586
> store_id: 1
> snapshot_id: 305
> created: 2015-06-15 06:06:22
> last_updated: NULL
> job_id: NULL
> store_role: Image
> size: 5368709120
> physical_size: 13312 ---> This is the size we are storing in the DB
> parent_snapshot_id: 0
> install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
> state: Ready
> update_count: 2
> ref_cnt: 0
> updated: 2015-06-15 06:06:36
> volume_id: 233
> 1 row in set (0.00 sec)
>  From File System:
> =
> [root@kirangoleta2 233]# ls -lh
> total 2.1M
> -rw-r--r--. 1 root root 2.1M Jun 15 11:36 
> e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size
> 3. From Xen Server:
> =
> xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all
> uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
> name-label ( RW): newtest_ROOT-203_20150615060620
> name-description ( RW):
> is-a-snapshot ( RO): true
> snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
> snapshots ( RO):
> snapshot-time ( RO): 20150615T06:09:29Z
> allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
> clone; copy; snapshot
> current-operations (SRO):
> sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
> sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
> vbd-uuids (SRO):
> crashdump-uuids (SRO):
> virtual-size ( RO): 5368709120
> physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
> consumed
> location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
> type ( RO): User
> sharable ( RO): false
> read-only ( RO): false
> storage-lock ( RO): false
> managed ( RO): true
> parent ( RO): 
> missing ( RO): false
> other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
> xenstore-data (MRO):
> sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
> on-boot ( RW): persist
> allow-caching ( RW): false
> metadata-latest ( RO): false
> metadata-of-pool ( RO): 
> tags (SRW):
> I see that we are storing the physical-utilisation reported by xen server.
> Interesting I see that ACS stores the physical file size in case of VMWare 
> environment,
> EXPECTED BEHAVIOR
> ==
> It is expected to see the physical size of the snapshot file in physical_size 
> column of the table "snapshot_store_ref
> ACTUAL BEHAVIOR
> ==
> In case of Xen Server ACS is storing physical-utilisation of the snapshot in 
> physical_size column of the table 

[jira] [Created] (CLOUDSTACK-9411) Resize Root Volume UI Element Not Visible By Domain Admins or Users

2016-06-09 Thread Andy Dills (JIRA)
Andy Dills created CLOUDSTACK-9411:
--

 Summary: Resize Root Volume UI Element Not Visible By Domain 
Admins or Users
 Key: CLOUDSTACK-9411
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9411
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.8.0
Reporter: Andy Dills


In the UI, the main Admin account is given the UI element to resize a root 
volume. However, Domain Admin and User accounts are never given the UI element. 
The UI element should appear with "Download Volume" and "Create Template" UI 
elements when the instance the volume is attached to is stopped.

Utilizing the API, Domain Admin and User accounts are able to successfully call 
resizeVolume.

This is quite limiting, as it is preferred to deploy minimal templates that 
users can then expand as needed. 



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


[jira] [Commented] (CLOUDSTACK-9404) Network ACL rules in VPCs are applied in an inverted order

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9404:


Github user dmabry commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
I tested this in our lab with advanced networking verified the patch is 
working as expected.  I used the following test process.

1. Created an acl and applied it to 1 VPC Network Tier.
``` 
10  192.168.10.0/24 Allow   ALL Ingress  
20  192.168.20.0/24 Allow   ALL Ingress 
30  192.168.30.0/24 Allow   ALL Ingress 
```
2. iptables looked like the following on the VPC VR
```
Chain ACL_INBOUND_eth2 (1 references)
target prot opt source   destination 
ACCEPT all  --  0.0.0.0/0225.0.0.50  
ACCEPT all  --  0.0.0.0/0224.0.0.18  
ACCEPT all  --  192.168.10.0/24  0.0.0.0/0   
ACCEPT all  --  192.168.20.0/24  0.0.0.0/0   
ACCEPT all  --  192.168.30.0/24  0.0.0.0/0   
DROP   all  --  0.0.0.0/00.0.0.0/0   
```
3. I added an additional rule of:
```
40  192.168.40.0/24 Allow   TCP 80  80  
Ingress 
```
4. iptables looked like the following on the VPC VR
```
Chain ACL_INBOUND_eth2 (1 references)
target prot opt source   destination 
ACCEPT all  --  0.0.0.0/0225.0.0.50  
ACCEPT all  --  0.0.0.0/0224.0.0.18  
ACCEPT all  --  192.168.10.0/24  0.0.0.0/0   
ACCEPT all  --  192.168.20.0/24  0.0.0.0/0   
ACCEPT all  --  192.168.30.0/24  0.0.0.0/0   
ACCEPT tcp  --  192.168.40.0/24  0.0.0.0/0tcp dpt:80
DROP   all  --  0.0.0.0/00.0.0.0/0   
```

In summary, it looks like this patch works verified by manual testing in my 
lab.

In short, LGTM based on testing.


> Network ACL rules in VPCs are applied in an inverted order
> --
>
> Key: CLOUDSTACK-9404
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9404
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.2, 4.8.0, 4.9.0
>Reporter: Patrick D.
>Assignee: Patrick D.
>
> Found the issue in the agent code. The comparator is inverted



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


[jira] [Commented] (CLOUDSTACK-9409) Usage server fails to work with 4.9 due to missing role_id column

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9409:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1584
  
Cool, thanks @swill!


> Usage server fails to work with 4.9 due to missing role_id column
> -
>
> Key: CLOUDSTACK-9409
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9409
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Blocker
>
> Thanks to Nicolas for reporting. The usage server fails to work due to 
> missing role_id column;
> 2016-06-07 11:04:51,233 ERROR [cloud.usage.UsageManagerImpl] 
> (Usage-Job-1:null) (logid:) Exception in usage manager
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@3202d58a: SELECT account.id, 
> account.account_name, account.type, account.role_id, account.domain_id, 
> account.state, account.removed, account.cleanup_needed, 
> account.network_domain, account.uuid, account.default_zone_id, 
> account.default FROM account WHERE account.id = 2
> ...
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown 
> column 'account.role_id' in 'field list'



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


[jira] [Commented] (CLOUDSTACK-9409) Usage server fails to work with 4.9 due to missing role_id column

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9409:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1584
  
Ok, thanks guys.  I will get this merged into 4.9.  Thank you for the bug 
report and fix...


> Usage server fails to work with 4.9 due to missing role_id column
> -
>
> Key: CLOUDSTACK-9409
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9409
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Blocker
>
> Thanks to Nicolas for reporting. The usage server fails to work due to 
> missing role_id column;
> 2016-06-07 11:04:51,233 ERROR [cloud.usage.UsageManagerImpl] 
> (Usage-Job-1:null) (logid:) Exception in usage manager
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@3202d58a: SELECT account.id, 
> account.account_name, account.type, account.role_id, account.domain_id, 
> account.state, account.removed, account.cleanup_needed, 
> account.network_domain, account.uuid, account.default_zone_id, 
> account.default FROM account WHERE account.id = 2
> ...
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown 
> column 'account.role_id' in 'field list'



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


[jira] [Commented] (CLOUDSTACK-9404) Network ACL rules in VPCs are applied in an inverted order

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9404:


Github user dmabry commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
I just kicked off a build that includes this PR.  I'm going to push this to 
our lab for testing and report back.


> Network ACL rules in VPCs are applied in an inverted order
> --
>
> Key: CLOUDSTACK-9404
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9404
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.2, 4.8.0, 4.9.0
>Reporter: Patrick D.
>Assignee: Patrick D.
>
> Found the issue in the agent code. The comparator is inverted



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


[jira] [Commented] (CLOUDSTACK-8922) Unable to delete IP tag

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-8922:


Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/905
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 170
 Hypervisor xenserver
 NetworkType Advanced
 Passed=73
 Failed=0
 Skipped=3

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


**Failed tests:**

**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_deploy_vgpu_enabled_vm

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


> Unable to delete IP tag
> ---
>
> Key: CLOUDSTACK-8922
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8922
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> 1. Acquire new IP address 
> 2. Create tags for the IP 
> 3. Delete the tag from Step#2 
>  an error occurs at Step#3 whereby the delete tag operation fails with 
> "Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] does not have 
> permission to operate within domain id\u003d632"
> TROUBLESHOOTING
> ==
> Acquire new IP address
> *
> {noformat}
> 2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-20:ctx-faed32b5 ctx-712308cb ctx-401bfcaf) submit async 
> job-72419, details: AsyncJobVO {id:72419, userId: 17, accountId: 15, 
> instanceType: IpAddress, instanceId: 672, cmd: 
> org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo: 
> {"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345048681027, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419) Executing AsyncJobVO {id:72419, 
> userId: 17, accountId: 15, instanceType: IpAddress, instanceId: 672, cmd: 
> org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo: 
> {"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345048681027, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-11-19 15:08:15,890 DEBUG [c.c.u.AccountManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Access to 
> Ntwk[216|Guest|8] granted to 
> Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] by DomainChecker
> 2014-11-19 15:08:15,911 DEBUG [c.c.n.IpAddressManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Successfully 
> associated ip address 210.140.170.160 to network Ntwk[216|Guest|8]
> 2014-11-19 15:08:15,922 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Complete async 
> job-72419, jobStatus: SUCCEEDED, resultCode: 0, result: 
> 

[jira] [Commented] (CLOUDSTACK-9409) Usage server fails to work with 4.9 due to missing role_id column

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9409:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1584
  
Thanks @rhtyd for this fix!

Just for the record, this was error before this fix:


2016-06-07 11:04:51,233 ERROR [cloud.usage.UsageManagerImpl] 
(Usage-Job-1:null) (logid:) Exception in usage manager
com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
com.mysql.jdbc.JDBC4PreparedStatement@3202d58a: SELECT account.id, 
account.account_name, account.type, account.role_id, account.domain_id, 
account.state, account.removed, account.cleanup_needed, account.network_domain, 
account.uuid, account.default_zone_id, account.default FROM account WHERE 
account.id = 2
...
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
Unknown column 'account.role_id' in 'field list' 


And now I can see usage jobs work properly:


2016-06-09 00:00:52,561 DEBUG [cloud.usage.UsageManagerImpl] 
(Usage-HB-1:null) (logid:) Scheduling Usage job...
2016-06-09 00:00:52,561 INFO  [cloud.usage.UsageManagerImpl] 
(Usage-Job-1:null) (logid:) starting usage job...
2016-06-09 00:00:52,568 INFO  [cloud.usage.UsageManagerImpl] 
(Usage-Job-1:null) (logid:) Parsing usage records between Wed Jun 08 00:00:00 
PDT 2016 and Wed Jun 08 23:59:59 PDT 2016

2016-06-09 00:00:53,436 INFO  [cloud.usage.UsageManagerImpl] 
(Usage-Job-1:null) (logid:) usage job complete


LGTM


> Usage server fails to work with 4.9 due to missing role_id column
> -
>
> Key: CLOUDSTACK-9409
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9409
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Blocker
>
> Thanks to Nicolas for reporting. The usage server fails to work due to 
> missing role_id column;
> 2016-06-07 11:04:51,233 ERROR [cloud.usage.UsageManagerImpl] 
> (Usage-Job-1:null) (logid:) Exception in usage manager
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@3202d58a: SELECT account.id, 
> account.account_name, account.type, account.role_id, account.domain_id, 
> account.state, account.removed, account.cleanup_needed, 
> account.network_domain, account.uuid, account.default_zone_id, 
> account.default FROM account WHERE account.id = 2
> ...
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown 
> column 'account.role_id' in 'field list'



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


[jira] [Commented] (CLOUDSTACK-9337) [CI] Enhance vcenter library to add datacenter programmatically

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9337:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1464
  
Master is frozen in prep for the 4.9 release. This will have to wait for 
4.10. 


> [CI] Enhance vcenter library to add datacenter programmatically
> ---
>
> Key: CLOUDSTACK-9337
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9337
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Enhance vcenter.py to create data centers in vCenter server automatically by 
> reading the configuration from a json file.
> Added few methods to create data center, cluster and hosts in it.



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


[jira] [Commented] (CLOUDSTACK-9389) [Automation ]modifying integration/smoke/test_routers_network_ops.py

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9389:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1563
  
This assumes that people know how to work with the test data and that they 
understand that "this random template needs X format and this other one will 
need Y format".  This is too much to ask without guidance, especially as we try 
to improve the automatability of the testing.  

The regex idea is not a perfect solution, but would allow for us to handle 
more template types with a single entry.  Ideally we would be able to specify 
the expected values for this type of thing in an OS specific way so the tested 
(and verified) values for each OS can live in the test data. It would probably 
need a default that is used if the current OS does not have a match. 

My main problem with this is that it will, by default,  break this test for 
everyone using bubble to automate their testing. Maybe we leave the old default 
test value in place, and people who are testing with other OSs can now override 
manually. 

What do you think? Sorry, I don't mean to be combative here, but this is a 
good opertunity for us to review the way we handle OS specific test data. 


> [Automation ]modifying integration/smoke/test_routers_network_ops.py
> 
>
> Key: CLOUDSTACK-9389
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9389
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
>
> Some test cases were failing due to invalid check_string , proposing 
> following modifications  
> 1-Moving check_string to test_data.py  
> 2-Since ping cmd reply is OS dependent ,for  default templates os type  
> CentOS changing check_string  from "3 packets received" to  "3 received" 
> [root@BPKxDmS ~]# ping -c 3 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=16.9 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=16.7 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=17.0 ms
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2020ms
> rtt min/avg/max/mdev = 16.720/16.896/17.015/0.196 ms



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


[jira] [Commented] (CLOUDSTACK-8939) VM Snapshot size with memory is not correctly calculated in cloud.usage_event (XenServer)

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-8939:


Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/914
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 167
 Hypervisor xenserver
 NetworkType Advanced
 Passed=73
 Failed=0
 Skipped=3

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


**Failed tests:**

**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_deploy_vgpu_enabled_vm

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


> VM Snapshot size with memory is not correctly calculated in cloud.usage_event 
> (XenServer)
> -
>
> Key: CLOUDSTACK-8939
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8939
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> 1. created a VM snapshot with memory on a VM with 512 MB RAM
> list all the VBDs for the VM
> xe vbd-list vm-name-label=i-2-43-VM empty=false params=vdi-uuid
> vdi-uuid ( RO): fbe638dd-02c5-42f5-96b2-7b3d73e68658
> Verify the size of the snapshot disk and its parent (I understand from the 
> code we only check one parent in the chain)
> # xe vdi-list params=physical-utilisation,sm-config,is-a-snapshot 
> uuid=fbe638dd-02c5-42f5-96b2-7b3d73e68658
> is-a-snapshot ( RO)   : false
> physical-utilisation ( RO): 38124032 <-
>sm-config (MRO): 
> host_OpaqueRef:52c1ec01-cef6-d4fd-7d81-68795a853ee0: RW; vhd-parent: 
> 993e3859-8be9-414c-819b-61095ab2eff1
> parent:
> # xe vdi-list params=physical-utilisation,sm-config,is-a-snapshot 
> uuid=993e3859-8be9-414c-819b-61095ab2eff1
> is-a-snapshot ( RO)   : false
> physical-utilisation ( RO): 119816704 <-
>sm-config (MRO): vhd-blocks: 
> eJxrYAAB0QcMWAELduFBDwSgNAsaHxcQARGMNHMOQfsJARFGRgkGRkWgOxmxGiWCwz5c9qLLU+o+YoGooIBUp6CgIJ2sIxnQKxzoZQ8M0Dof09s/1AMALcYD3A==;
>  vhd-parent: 4b7ee66c-de53-47bb-b3d5-306d40a0ea08
> At this stage, not counting the "suspend VDI", the size looks as follows: 
> 38124032 + 119816704 = 157940736 = 150.6 MB
> Now, let's calulate the "suspend VDI" size and add it to the above value:
> Note my test VM has 512 MB of RAM
> # xe vdi-list name-label=Suspend\ image params=all
> uuid ( RO): e2ae7a47-c410-479b-9e2b-5f05c01f1b4f
>   name-label ( RW): Suspend image
> name-description ( RW): Suspend image
>is-a-snapshot ( RO): true
> physical-utilisation ( RO): 6144  
> <--- 
>sm-config (MRO): vhd-parent: 
> c286583b-dd47-4a21-a5fe-ba2f671f1163
> Looking at the parent
> # xe vdi-list uuid=c286583b-dd47-4a21-a5fe-ba2f671f1163 params=all
> uuid ( RO): c286583b-dd47-4a21-a5fe-ba2f671f1163
>   name-label ( RW): base copy
>is-a-snapshot ( RO): false
> virtual-size ( RO): 782237696
> physical-utilisation ( RO): 252154368 
> <--- 
>sm-config (MRO): vhd-blocks: eJz7/x8ZNDA0MEDAASiNyucAAHMeEPs=
>  
> So the "suspend VDI" + its parent has "physical utilisation" of 6144 + 
> 252154368 = 252160512 = 17.55 MB
> Now, if we add it to the previously calculated disk sizes, we'll get:
> xapi (phys util): 157940736 (non-memory snap disks)+ 252160512 (memory snap 
> disks) = 410101248 = 391.1 MB
> Let's verify the size in cloud.usage_event now:
> select * from cloud.usage_event where  resource_name like "i-2-43-VM%" \G
>   
>   
>id: 528 

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

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9319:


Github user insom commented on the issue:

https://github.com/apache/cloudstack/pull/1451
  
@bvbharatk Hi, am I supposed to do something with this CI output? It looks 
like all of the errors are related to other parts of CloudStack that aren't 
touched by my commits. I came back to check on this bug because I got bitten by 
this again today (timeout when adding rules to a virtual router, but the 
timeout is actually not getting applied properly).


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



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


[jira] [Commented] (CLOUDSTACK-9328) Fix vlan issues from test suite test_privategw_acl.py in BVT

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9328:


Github user sanju1010 commented on the issue:

https://github.com/apache/cloudstack/pull/1455
  
Failures from CI are not related to changes in this file. This commit makes 
changes to test_privategw_acl.py


> Fix vlan issues from test suite test_privategw_acl.py in BVT
> 
>
> Key: CLOUDSTACK-9328
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9328
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Fix vlan issues from test suite test_privategw_acl.py in BVT
> Currently the tests reads the vlans from the physical network and takes the 
> first vlan from the list of vlans and uses it. However, this approach might 
> not work when the tests run in parallel. E.g. in CI we run test suits in 
> parallel and the first vlan may not be available and tests would fail if we 
> try to use the vlan which is already in use.
> Made changes to the script so that it will get the free vlan list from the DB 
> and uses the first vlan from the available pool.



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


[jira] [Commented] (CLOUDSTACK-9353) NullPointerException when migrating VMs with local storage

2016-06-09 Thread Anshul Gangwar (JIRA)

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

Anshul Gangwar commented on CLOUDSTACK-9353:


Bug got introduced due to below commit 

commit 858b87f01c079f48ed557864be4842d6becaa55c
Author: wilderrodrigues 
Date:   Fri Apr 3 14:39:35 2015 +0200

Fix will be to use list form of volumeToFiler in 
XenServer610MigrateWithStorageCommandWrapper.execute() method as shown below
 List> volumeToFiler = 
cmd.getVolumeToFilerAsList();

> NullPointerException when migrating VMs with local storage
> --
>
> Key: CLOUDSTACK-9353
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9353
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.7.1, 4.8.0
> Environment: CloudStack 4.7.1 on CentOS 6.X; XenServer 6.5 with 
> latest patches applied
>Reporter: Dave Garbus
>Priority: Critical
>
> When attempting to live migrate VMs with local storage, the following NPE is 
> received:
> {quote}
> 2016-04-18 12:19:40,264 ERROR [o.a.c.s.m.XenServerStorageMotionStrategy] 
> (Work-Job-Executor-6:ctx-5f0d0c55 job-214100/job-214101 ctx-a0a3ff72) 
> (logid:f799420c) Migration with storage of vm VM[User|i-2-1032-VM] failed. 
> Details: Exception: java.lang.NullPointerException
> Message: null
> Stack: java.lang.NullPointerException
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xen610.XenServer610MigrateWithStorageCommandWrapper.execute(XenServer610MigrateWithStorageCommandWrapper.java:86)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xen610.XenServer610MigrateWithStorageCommandWrapper.execute(XenServer610MigrateWithStorageCommandWrapper.java:54)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:1676)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> 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 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2016-04-18 12:19:40,265 ERROR [o.a.c.s.m.XenServerStorageMotionStrategy] 
> (Work-Job-Executor-6:ctx-5f0d0c55 job-214100/job-214101 ctx-a0a3ff72) 
> (logid:f799420c) copy failed
> com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm 
> VM[User|i-2-1032-VM] to host Host[-41-Routing]. Exception: 
> java.lang.NullPointerException
> Message: null
> Stack: java.lang.NullPointerException
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xen610.XenServer610MigrateWithStorageCommandWrapper.execute(XenServer610MigrateWithStorageCommandWrapper.java:86)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xen610.XenServer610MigrateWithStorageCommandWrapper.execute(XenServer610MigrateWithStorageCommandWrapper.java:54)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:1676)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> 

[jira] [Commented] (CLOUDSTACK-9389) [Automation ]modifying integration/smoke/test_routers_network_ops.py

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9389:


Github user nitt10prashant commented on the issue:

https://github.com/apache/cloudstack/pull/1563
  
-->I think it is important that the test data does not need to be changed 
for our automated(ish) CI to show the tests are passing
@swill  i think test-data meant to be changed depend on your local 
environment and every one should have local copy of their own test data .



> [Automation ]modifying integration/smoke/test_routers_network_ops.py
> 
>
> Key: CLOUDSTACK-9389
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9389
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
>
> Some test cases were failing due to invalid check_string , proposing 
> following modifications  
> 1-Moving check_string to test_data.py  
> 2-Since ping cmd reply is OS dependent ,for  default templates os type  
> CentOS changing check_string  from "3 packets received" to  "3 received" 
> [root@BPKxDmS ~]# ping -c 3 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=16.9 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=16.7 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=17.0 ms
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2020ms
> rtt min/avg/max/mdev = 16.720/16.896/17.015/0.196 ms



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


[jira] [Commented] (CLOUDSTACK-9328) Fix vlan issues from test suite test_privategw_acl.py in BVT

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9328:


Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/1455
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 166
 Hypervisor xenserver
 NetworkType Advanced
 Passed=70
 Failed=3
 Skipped=3

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


**Failed tests:**
* test_vpc_vpn.py

 * ContextSuite context=TestRVPCSite2SiteVpn>:setup Failing since 17 runs

 * ContextSuite context=TestVpcRemoteAccessVpn>:setup Failing since 17 runs

 * ContextSuite context=TestVpcSite2SiteVpn>:setup Failing since 17 runs


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
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_routers.py
test_reset_vm_on_reboot.py
test_snapshots.py
test_deploy_vms_with_varied_deploymentplanners.py
test_login.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_disk_offerings.py


> Fix vlan issues from test suite test_privategw_acl.py in BVT
> 
>
> Key: CLOUDSTACK-9328
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9328
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Fix vlan issues from test suite test_privategw_acl.py in BVT
> Currently the tests reads the vlans from the physical network and takes the 
> first vlan from the list of vlans and uses it. However, this approach might 
> not work when the tests run in parallel. E.g. in CI we run test suits in 
> parallel and the first vlan may not be available and tests would fail if we 
> try to use the vlan which is already in use.
> Made changes to the script so that it will get the free vlan list from the DB 
> and uses the first vlan from the available pool.



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


[jira] [Commented] (CLOUDSTACK-9337) [CI] Enhance vcenter library to add datacenter programmatically

2016-06-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-9337:


Github user sanju1010 commented on the issue:

https://github.com/apache/cloudstack/pull/1464
  
@swill , BVT results are clean. Can we push this to master? This will not 
have any impact on acs master stablity.


> [CI] Enhance vcenter library to add datacenter programmatically
> ---
>
> Key: CLOUDSTACK-9337
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9337
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Enhance vcenter.py to create data centers in vCenter server automatically by 
> reading the configuration from a json file.
> Added few methods to create data center, cluster and hosts in it.



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