[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

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

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1706
  
@jburwell #1659 has a fix which complements this patch.Basically when first 
IP is associated with an interface routing table is created and should be 
deleted when last IP associated is removed. #1659 handles that case.

@vilisseranen  could you please see if there is regression. Looks like IP 
may be getting removed from ips.json data bag, but not really getting 
dis-associated from the interface. Failure in below tests indicate so.

test_network_rules_acquired_public_ip_3_Load_Balancer_Rule  Failure 36.36   
test_network.py
test_network_rules_acquired_public_ip_2_nat_ruleFailure 31.31   
test_network.py
est_network_rules_acquired_public_ip_1_static_nat_rule  Failure 93.29   
test_network.py




> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



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


[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

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

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

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1745
  
@jburwell I'm running tests on 4.8+ branches to see what tests may have 
regressed on these branches.
PR #1752  - 4.8
PR #1753  - 4.9
PR #1754  - 4.10

@blueorangutan package


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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


[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

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

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

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user blueorangutan commented on the issue:

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


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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


[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

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

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

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user blueorangutan commented on the issue:

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


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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


[jira] [Created] (CLOUDSTACK-9584) Increase component tests coverage in Travis run

2016-11-09 Thread Rohit Yadav (JIRA)
Rohit Yadav created CLOUDSTACK-9584:
---

 Summary: Increase component tests coverage in Travis run
 Key: CLOUDSTACK-9584
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9584
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rohit Yadav
Assignee: Rohit Yadav


Increase component tests in Travis for PRs.



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


[jira] [Commented] (CLOUDSTACK-9584) Increase component tests coverage in Travis run

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

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

ASF GitHub Bot commented on CLOUDSTACK-9584:


GitHub user rhtyd opened a pull request:

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

CLOUDSTACK-9584: run component tests in Travis run

This would run additional component tests in Travis run.

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

$ git pull https://github.com/shapeblue/cloudstack 4.9-component-tests

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

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


commit 29918686323f2480ad44285800bda87aa19ede7b
Author: Rohit Yadav 
Date:   2016-11-09T13:34:17Z

CLOUDSTACK-9584: run component tests in Travis run

This would run additional component tests in Travis run

Signed-off-by: Rohit Yadav 




> Increase component tests coverage in Travis run
> ---
>
> Key: CLOUDSTACK-9584
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9584
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> Increase component tests in Travis for PRs.



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


[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

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

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

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@murali-reddy could you please update the commit message/pull request 
description to describe the motivation for this change and the benefits it 
provides?  Also, this fix would be useful for 4.8 user as well.  Therefore, 
could you please change the base branch to 4.8?


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



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


[jira] [Created] (CLOUDSTACK-9585) UI doesn't give an option to select the xentools version for non ROOT users

2016-11-09 Thread subhash yedugundla (JIRA)
subhash yedugundla created CLOUDSTACK-9585:
--

 Summary: UI doesn't give an option to select the xentools version 
for non ROOT users
 Key: CLOUDSTACK-9585
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9585
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.8.0
 Environment: Xen Server
Reporter: subhash yedugundla
 Fix For: 4.8.1


UI doesn't give an option to select the xentools version while registering 
template for any user other than ROOT admin. Templates registered by other 
users are marked as 'xenserver56' and results in unsusable VMs due to the 
device_id:002 issue with windows if the template is having xentools version 
higher than 6.1 .

Repro Steps
Select register template as any other user than ROOT domain admin and UI 
doesn't give an option to select the xentools version.




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


[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

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

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

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
Trillian test result (tid-316)
Environment: kvm-centos6 (x2), Advanced Networking with Mgmt server 7
Total time taken: 28592 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1750-t316-kvm-centos6.zip
Test completed. 47 look ok, 1 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | 
test_list_ids_parameter.py
test_01_vpc_site2site_vpn | Success | 170.08 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 81.28 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 291.29 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 350.77 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 734.01 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 578.39 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1443.74 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 621.32 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 777.42 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1370.08 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.60 | test_volumes.py
test_08_resize_volume | Success | 15.41 | test_volumes.py
test_07_resize_fail | Success | 20.48 | test_volumes.py
test_06_download_detached_volume | Success | 15.30 | test_volumes.py
test_05_detach_volume | Success | 100.23 | test_volumes.py
test_04_delete_attached_volume | Success | 10.24 | test_volumes.py
test_03_download_attached_volume | Success | 15.29 | test_volumes.py
test_02_attach_volume | Success | 107.21 | test_volumes.py
test_01_create_volume | Success | 862.39 | test_volumes.py
test_deploy_vm_multiple | Success | 293.71 | 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 | 27.06 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 81.10 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.11 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.77 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.77 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.16 | test_vm_life_cycle.py
test_01_stop_vm | Success | 125.81 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 151.16 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.05 | test_templates.py
test_04_extract_template | Success | 5.17 | test_templates.py
test_03_delete_template | Success | 5.14 | test_templates.py
test_02_edit_template | Success | 90.18 | test_templates.py
test_01_create_template | Success | 65.67 | test_templates.py
test_10_destroy_cpvm | Success | 161.97 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.92 | test_ssvm.py
test_08_reboot_cpvm | Success | 131.75 | test_ssvm.py
test_07_reboot_ssvm | Success | 134.11 | test_ssvm.py
test_06_stop_cpvm | Success | 167.24 | test_ssvm.py
test_05_stop_ssvm | Success | 134.42 | test_ssvm.py
test_04_cpvm_internals | Success | 1.50 | test_ssvm.py
test_03_ssvm_internals | Success | 3.62 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py
test_04_change_offering_small | Success | 243.10 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.09 | test_service_offerings.py
test_01_create_service_offering | Success | 0.10 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.12 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py
test_09_reboot_router | Success | 40.32 | test_routers.py
test_08_start_router | Success | 40.37 | test_routers.py
test_07_stop_router | Success | 10.15 | test_routers.py
test_06_router_advanced | Success | 0.08 | test_routers.py
test_05_router_basic | Success | 0.04 | test_routers.py
test_04_restart_network_wo_cleanup | Success | 5.82 | test_r

[jira] [Commented] (CLOUDSTACK-9585) UI doesn't give an option to select the xentools version for non ROOT users

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

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

ASF GitHub Bot commented on CLOUDSTACK-9585:


GitHub user yvsubhash opened a pull request:

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

CLOUDSTACK-9585 UI doesn't give an option to select the xentools version

UI doesn't give an option to select the xentools version while registering 
template for any user other than ROOT admin. Templates registered by other 
users are marked as 'xenserver56' and results in unsusable VMs due to the 
device_id:002 issue with windows if the template is having xentools version 
higher than 6.1 .
Repro Steps
Select register template as any other user than ROOT domain admin and UI 
doesn't give an option to select the xentools version.

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

$ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-9585

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

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


commit f64c7cb5cfa75c2c1ca57d84177ad741817b1cc8
Author: subhash yedugundla 
Date:   2016-06-22T09:27:08Z

CLOUDSTACK-9585 UI doesn't give an option to select the xentools version




> UI doesn't give an option to select the xentools version for non ROOT users
> ---
>
> Key: CLOUDSTACK-9585
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9585
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.8.0
> Environment: Xen Server
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> UI doesn't give an option to select the xentools version while registering 
> template for any user other than ROOT admin. Templates registered by other 
> users are marked as 'xenserver56' and results in unsusable VMs due to the 
> device_id:002 issue with windows if the template is having xentools version 
> higher than 6.1 .
> Repro Steps
> Select register template as any other user than ROOT domain admin and UI 
> doesn't give an option to select the xentools version.



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


[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage

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

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

ASF GitHub Bot commented on CLOUDSTACK-9401:


Github user prashanthvarma commented on the issue:

https://github.com/apache/cloudstack/pull/1578
  
@jburwell @rhtyd We were able to successfully run the failing test 
"test_01_create_template" on our kvm-centos7 environment with this PR build 
after dealing with the issue on ACS-KVM agent (missing semi-colon in systemd 
file), which was fixed on master today. 

Adding to our last two comments, all the above test failures are most 
likely test environment (or) timing issues. Please do reconsider this PR for 
review and merging into master for 4.10 RC.

Here are the test run logs:

[results.txt](https://github.com/apache/cloudstack/files/581418/results.txt)
[runinfo.txt](https://github.com/apache/cloudstack/files/581417/runinfo.txt)

Test create public & private template ... === TestName: 
test_01_create_template | Status : SUCCESS ===
ok

--
Ran 1 test in 541.353s

OK


> Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
> -
>
> Key: CLOUDSTACK-9401
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9401
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> Supporting Internal Dns by using Dns service provider as Virtual Router but 
> Dhcp provider will be NuageVsp. The idea is here is to keep using Internal 
> Dns service of cloudstack when network provider is some other vendor.
> A sample network offering will be like below one:-
> Service   Provider
> DHCP NuageVsp
> DNSVirtualRouter/VpcVirtualRouter
> UserDataVirtualRouter/VpcVirtualRouter
> Virtual Networking   NuageVsp
> SourceNat   NuageVsp
> StaticNat NuageVsp
> NetworkAcl/FirewallNuageVsp
> Testrun:-
> Verify InternalDns on Isolated Network ... === TestName: 
> test_01_Isolated_Network_with_zone | Status : SUCCESS ===
> ok
> Verify InternalDns on Isolated Network with ping by hostname ... === 
> TestName: test_02_Isolated_Network | Status : SUCCESS ===
> ok
> Verify update NetworkDomain for InternalDns on Isolated Network ... === 
> TestName: test_03_Update_Network_with_Domain | Status : SUCCESS ===
> ok
> Verify update NetworkDomain for InternalDns on Isolated Network with ping VM 
> ... === TestName: test_04_Update_Network_with_Domain | Status : SUCCESS ===
> ok
> Verify InternalDns on VPC Network ... === TestName: 
> test_05_VPC_Network_With_InternalDns | Status : SUCCESS ===
> ok
> Verify InternalDns on VPC Network by ping with hostname ... === TestName: 
> test_06_VPC_Network_With_InternalDns | Status : SUCCESS ===
> ok
> --
> Ran 6 tests in 5736.562s
> OK
> cloudstack$ pep8 --max-line-length=150 test_internal_dns.py
> cloudstack$  pyflakes test_internal_dns.py
> cloudstack$



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


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

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

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

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-320)
Environment: kvm-centos6 (x2), Advanced Networking with Mgmt server 7
Total time taken: 28892 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1727-t320-kvm-centos6.zip
Test completed. 47 look ok, 1 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | 
test_list_ids_parameter.py
test_01_vpc_site2site_vpn | Success | 180.46 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 71.18 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 266.86 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 363.50 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 703.04 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 551.06 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1352.57 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 622.84 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 783.62 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1334.33 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.83 | test_volumes.py
test_08_resize_volume | Success | 15.45 | test_volumes.py
test_07_resize_fail | Success | 20.60 | test_volumes.py
test_06_download_detached_volume | Success | 15.39 | test_volumes.py
test_05_detach_volume | Success | 100.27 | test_volumes.py
test_04_delete_attached_volume | Success | 10.24 | test_volumes.py
test_03_download_attached_volume | Success | 15.35 | test_volumes.py
test_02_attach_volume | Success | 107.05 | test_volumes.py
test_01_create_volume | Success | 867.24 | test_volumes.py
test_deploy_vm_multiple | Success | 268.72 | 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.73 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.27 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 56.13 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.14 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 130.96 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.92 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.19 | test_vm_life_cycle.py
test_01_stop_vm | Success | 125.96 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 121.89 | test_templates.py
test_08_list_system_templates | Success | 0.04 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.07 | test_templates.py
test_04_extract_template | Success | 5.22 | test_templates.py
test_03_delete_template | Success | 5.12 | test_templates.py
test_02_edit_template | Success | 90.11 | test_templates.py
test_01_create_template | Success | 75.76 | test_templates.py
test_10_destroy_cpvm | Success | 162.29 | test_ssvm.py
test_09_destroy_ssvm | Success | 194.63 | test_ssvm.py
test_08_reboot_cpvm | Success | 132.15 | test_ssvm.py
test_07_reboot_ssvm | Success | 134.08 | test_ssvm.py
test_06_stop_cpvm | Success | 132.07 | test_ssvm.py
test_05_stop_ssvm | Success | 164.44 | test_ssvm.py
test_04_cpvm_internals | Success | 1.89 | test_ssvm.py
test_03_ssvm_internals | Success | 3.77 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.14 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.15 | test_ssvm.py
test_04_change_offering_small | Success | 244.79 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.05 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.10 | test_service_offerings.py
test_01_create_service_offering | Success | 0.14 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py
test_09_reboot_router | Success | 40.40 | test_routers.py
test_08_start_router | Success | 35.34 | test_routers.py
test_07_stop_router | Success | 10.16 | test_routers.py
test_06_router_advanced | Success | 0.06 | test_routers.py
test_05_router_basic | Success | 0.04 | test_routers.py
test_04_restart_network_wo_cleanup | Success | 5.83 | test_r

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

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

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

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
Trillian test result (tid-319)
Environment: kvm-centos6 (x2), Advanced Networking with Mgmt server 7
Total time taken: 33284 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1750-t319-kvm-centos6.zip
Test completed. 38 look ok, 10 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_vpc_site2site_vpn | `Failure` | 179.81 | test_vpc_vpn.py
test_02_VPC_default_routes | `Failure` | 797.42 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | `Failure` | 876.10 | 
test_vpc_router_nics.py
test_05_rvpc_multi_tiers | `Failure` | 354.61 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | `Failure` | 109.04 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
`Failure` | 119.45 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | `Failure` | 160.49 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 360.95 
| test_vpc_redundant.py
test_04_change_offering_small | `Failure` | 799.64 | 
test_service_offerings.py
test_router_dns_guestipquery | `Failure` | 277.52 | test_router_dns.py
test_04_rvpc_privategw_static_routes | `Failure` | 376.75 | 
test_privategw_acl.py
test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 929.63 | 
test_privategw_acl.py
test_02_vpc_privategw_static_routes | `Failure` | 949.48 | 
test_privategw_acl.py
test_isolate_network_password_server | `Failure` | 188.67 | 
test_password_server.py
test_reboot_router | `Failure` | 429.54 | test_network.py
test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | `Failure` | 
832.13 | test_network.py
test_network_rules_acquired_public_ip_2_nat_rule | `Failure` | 679.85 | 
test_network.py
test_network_rules_acquired_public_ip_1_static_nat_rule | `Failure` | 
675.65 | test_network.py
test_02_port_fwd_on_non_src_nat | `Failure` | 678.86 | test_network.py
test_01_port_fwd_on_src_nat | `Failure` | 673.73 | test_network.py
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | `Failure` | 225.13 | 
test_internal_lb.py
test_01_redundant_vpc_site2site_vpn | `Error` | 416.66 | test_vpc_vpn.py
test_05_rvpc_multi_tiers | `Error` | 637.00 | test_vpc_redundant.py
ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | 
test_list_ids_parameter.py
test_03_vpc_internallb_haproxy_stats_on_all_interfaces | `Error` | 205.10 | 
test_internal_lb.py
test_01_vpc_remote_access_vpn | Success | 66.34 | test_vpc_vpn.py
test_09_delete_detached_volume | Success | 15.55 | test_volumes.py
test_08_resize_volume | Success | 15.43 | test_volumes.py
test_07_resize_fail | Success | 20.51 | test_volumes.py
test_06_download_detached_volume | Success | 15.33 | test_volumes.py
test_05_detach_volume | Success | 100.29 | test_volumes.py
test_04_delete_attached_volume | Success | 10.23 | test_volumes.py
test_03_download_attached_volume | Success | 15.32 | test_volumes.py
test_02_attach_volume | Success | 77.81 | test_volumes.py
test_01_create_volume | Success | 758.71 | test_volumes.py
test_deploy_vm_multiple | Success | 334.24 | 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.76 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.25 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 40.96 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.88 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.98 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.20 | test_vm_life_cycle.py
test_01_stop_vm | Success | 125.99 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 146.18 | 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.38 | test_templates.py
test_03_delete_template | Success | 5.10 | test_templates.py
test_02_edit_template | Success | 90.15 | test_templates.py
test_01_create_template | Success | 85.81 | test_templates.py
test_10_destroy_cpvm | Success | 227.04 | test_ssvm.py
test_09_destroy_ssvm | Success | 194.48 | test_ssvm.py
 

[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

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

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1706
  
Trillian test result (tid-315)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 36714 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1706-t315-vmware-55u3.zip
Test completed. 44 look ok, 4 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | `Failure` | 
41.83 | test_network.py
test_network_rules_acquired_public_ip_2_nat_rule | `Failure` | 31.59 | 
test_network.py
test_network_rules_acquired_public_ip_1_static_nat_rule | `Failure` | 94.90 
| test_network.py
test_01_vpc_site2site_vpn | `Error` | 486.90 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | `Error` | 743.77 | test_vpc_vpn.py
test_06_stop_cpvm | `Error` | 415.91 | test_ssvm.py
test_01_snapshot_root_disk | `Error` | 15.22 | test_snapshots.py
ContextSuite context=TestSnapshotRootDisk>:teardown | `Error` | 65.58 | 
test_snapshots.py
test_01_vpc_remote_access_vpn | Success | 146.77 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 315.46 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 747.72 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 683.07 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1554.80 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 680.07 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 719.78 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1473.36 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 25.98 | test_volumes.py
test_06_download_detached_volume | Success | 60.67 | test_volumes.py
test_05_detach_volume | Success | 100.27 | test_volumes.py
test_04_delete_attached_volume | Success | 10.22 | test_volumes.py
test_03_download_attached_volume | Success | 20.39 | test_volumes.py
test_02_attach_volume | Success | 53.78 | test_volumes.py
test_01_create_volume | Success | 460.61 | test_volumes.py
test_03_delete_vm_snapshots | Success | 280.27 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 237.15 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 146.47 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 161.87 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 253.77 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.94 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.20 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 71.09 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.16 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.15 | test_vm_life_cycle.py
test_02_start_vm | Success | 20.26 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.16 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 262.25 | 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 | 15.39 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.17 | test_templates.py
test_01_create_template | Success | 126.13 | test_templates.py
test_10_destroy_cpvm | Success | 328.61 | test_ssvm.py
test_09_destroy_ssvm | Success | 299.93 | test_ssvm.py
test_08_reboot_cpvm | Success | 186.65 | test_ssvm.py
test_07_reboot_ssvm | Success | 158.82 | test_ssvm.py
test_05_stop_ssvm | Success | 183.74 | test_ssvm.py
test_04_cpvm_internals | Success | 1.41 | test_ssvm.py
test_03_ssvm_internals | Success | 4.06 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py
test_04_change_offering_small | Success | 96.90 | 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 | 0.09 | test_se

[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

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

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1706
  
@murali-reddy should we merge #1659 and then re-base this PR before running 
more tests?


> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



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


[jira] [Created] (CLOUDSTACK-9586) When using shared storage with Xenserver prepareTemplate does not work

2016-11-09 Thread Abhinandan Prateek (JIRA)
Abhinandan Prateek created CLOUDSTACK-9586:
--

 Summary: When using shared storage with Xenserver prepareTemplate 
does not work
 Key: CLOUDSTACK-9586
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Abhinandan Prateek



2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor] 
(DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
SR_BACKEND_FAILURE_40The SR scan failed  [opterr=['INTERNAL_ERROR', 
'Db_exn.Uniqueness_constraint_violation("VDI", "uuid", 
"703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
at 
com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
at com.xensource.xenapi.SR.scan(SR.java:1257)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)

Root Cause: CloudPlatform creates a SR on each host, which points to the 
template location on the secondary storage 
(secondary_Storage/template/tmpl//). This causes the 
database unique constraint violation when each XenServer tries to scan the SR 
created on each host. The host that scans the SR last, throws the exception 
because VDI was recognized already from the SR scan of the first host.



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


[jira] [Updated] (CLOUDSTACK-9586) When using shared storage with Xenserver prepareTemplate does not work

2016-11-09 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-9586:
---
 Assignee: Abhinandan Prateek
Affects Version/s: 4.5.2
Fix Version/s: 4.5.2.2
  Description: 
2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor] 
(DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
SR_BACKEND_FAILURE_40The SR scan failed  [opterr=['INTERNAL_ERROR', 
'Db_exn.Uniqueness_constraint_violation("VDI", "uuid", 
"703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
at 
com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
at com.xensource.xenapi.SR.scan(SR.java:1257)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)

Root Cause: CloudPlatform creates a SR on each host, which points to the 
template location on the secondary storage 
(secondary_Storage/template/tmpl//). This causes the 
database unique constraint violation when each XenServer tries to scan the SR 
created on each host. The host that scans the SR last, throws the exception 
because VDI was recognized already from the SR scan of the first host.

  was:

2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor] 
(DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
SR_BACKEND_FAILURE_40The SR scan failed  [opterr=['INTERNAL_ERROR', 
'Db_exn.Uniqueness_constraint_violation("VDI", "uuid", 
"703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
at 
com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
at com.xensource.xenapi.SR.scan(SR.java:1257)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
at 
com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)

Root Cause: CloudPlatform creates a SR on each host, which points to the 
template location on the secondary storage 
(secondary_Storage/template/tmpl//). This causes the 
database unique constraint violation when each XenServer tries to scan the SR 
created on each host. The host that scans the SR last, throws the exception 
because VDI was recognized already from the SR scan of the first host.


> When using shared storage with Xenserver prepareTemplate does not work
> --
>
> Key: CLOUDSTACK-9586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.5.2.2
>
>
> 2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor] 
> (DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
> SR_BACKEND_FAILURE_40The SR scan failed  [opterr=['INTERNAL_ERROR', 
> 'Db_exn.Uniqueness_constraint_violation("VDI", "uuid", 
> "703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
>   at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
>   at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
>   at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
>   at com.xensource.xenapi.SR.scan(SR.java:1257)
>   at 
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
>   at 
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
>   at 
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)
> Root Cause: CloudPlatform creates a SR on each host, which points to the 
> template location on the secondary storage 
> (secondary_Storage/templ

[jira] [Updated] (CLOUDSTACK-9586) When using shared storage with Xenserver prepareTemplate does not work when there are more than 1 hosts

2016-11-09 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-9586:
---
Summary: When using shared storage with Xenserver prepareTemplate does not 
work when there are more than 1 hosts  (was: When using shared storage with 
Xenserver prepareTemplate does not work)

> When using shared storage with Xenserver prepareTemplate does not work when 
> there are more than 1 hosts
> ---
>
> Key: CLOUDSTACK-9586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.5.2.2
>
>
> 2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor] 
> (DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
> SR_BACKEND_FAILURE_40The SR scan failed  [opterr=['INTERNAL_ERROR', 
> 'Db_exn.Uniqueness_constraint_violation("VDI", "uuid", 
> "703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
>   at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
>   at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
>   at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
>   at com.xensource.xenapi.SR.scan(SR.java:1257)
>   at 
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
>   at 
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
>   at 
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)
> Root Cause: CloudPlatform creates a SR on each host, which points to the 
> template location on the secondary storage 
> (secondary_Storage/template/tmpl//). This causes the 
> database unique constraint violation when each XenServer tries to scan the SR 
> created on each host. The host that scans the SR last, throws the exception 
> because VDI was recognized already from the SR scan of the first host.



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


[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

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

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

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy closed the pull request at:

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


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



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