[jira] [Commented] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Harikrishna Patnala (JIRA)]

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

Harikrishna Patnala commented on CLOUDSTACK-7351:
-

I wonder how the test was passed before my fix.
Without the hypervisor type how can a vm is deployed using ISO !

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-7146) [Automation] Fix the scripts "test_assign_vm.py, test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py" - Cleanup of domain should be done after

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye reassigned CLOUDSTACK-7146:
--

Assignee: Gaurav Aradhye  (was: Girish Shilamkar)

> [Automation] Fix the scripts "test_assign_vm.py, 
> test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py" - 
> Cleanup of domain should be done after cleaning up account in it
> --
>
> Key: CLOUDSTACK-7146
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7146
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> 
> *Error Messages:*
> 
> ---
> *One:*
> ---
> {code}
> test_16_move_across_subdomain_volume_and_account_limit 
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Payload: 
> {'signature': 'ctoosHX10fXC2XJv8iFdUiNqV5Q=', 'apiKey': 
> u'K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA',
>  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
> u'ebbf78c7-5a1d-4051-8404-26314a59151a'}
> test_16_move_across_subdomain_volume_and_account_limit 
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: 
> Sending GET Cmd : queryAsyncJobResult===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.220.135.41
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?signature=ctoosHX10fXC2XJv8iFdUiNqV5Q%3D&apiKey=K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA&command=queryAsyncJobResult&response=json&jobid=ebbf78c7-5a1d-4051-8404-26314a59151a
>  HTTP/1.1" 200 477
> test_16_move_across_subdomain_volume_and_account_limit 
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
> {jobprocstatus : 0, created : u'2014-07-11T16:11:24+', cmd : 
> u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
> u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
> u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the 
> domain yet because it has 1 accounts to cleanup"}, accountid : 
> u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
> test_16_move_across_subdomain_volume_and_account_limit 
> (integration.component.test_assign_vm.TestVMOwnership): ERROR:  __poll: 
> Exception Occurred :Job failed: {jobprocstatus : 0, created : 
> u'2014-07-11T16:11:24+', cmd : 
> u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
> u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
> u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the 
> domain yet because it has 1 accounts to cleanup"}, accountid : 
> u'ce30160a-0901-11e4-a9bc-5a9383355ca2'} 
> Traceback (most recent call last):
>   File 
> "/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
>  line 105, in __poll
> % async_response)
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-07-11T16:11:24+', cmd : 
> u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
> u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
> u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the 
> domain yet because it has 1 accounts to cleanup"}, accountid : 
> u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
> test_16_move_across_subdomain_volume_and_account_limit 
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
> FAILED
> test_16_move_across_subdomain_volume_and_account_limit 
> (integration.component.test_assign_vm.TestVMOwnership): ERROR: marvinRequest 
> : CmdName:  0x3844810> Exception: ['Traceback (most recent call last):\n', '  File 
> "/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
>  line 375, in marvinRequest\nraise self.__lastError\n', 'Exception: Job 
> failed: {jobprocstatus : 0, created : u\'2014-07-11T16:11:24+\', cmd : 
> u\'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd\', userid : 
> u\'ce302410-0901-11e4-a9bc-5a9383355ca2\', jobstatu

[jira] [Closed] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT

[Sanjeev N (JIRA)]

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

Sanjeev N closed CLOUDSTACK-7188.
-

Resolution: Fixed

This issue has been fixed in CS-7190

> [Automation]Add hyper-v support for test_ssvm.py suite in BVT
> -
>
> Key: CLOUDSTACK-7188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest master build
>Reporter: Sanjeev N
>  Labels: automation
>
> [Automation]Add hyper-v support for test_ssvm.py suite in BVT
> 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests 
> require ssh access to ssvm/cpvm. Right now the tests have ssh access 
> mechanism supported only for vmware,xen and kvm.
> This bug is to add ssh access support for Hyper-v as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT

[Sanjeev N (JIRA)]

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

Sanjeev N closed CLOUDSTACK-7189.
-

Resolution: Fixed

This issue has been fixed in CS-7190

> [Automation]Add hyper-v support for test_routers.py suite in BVT
> 
>
> Key: CLOUDSTACK-7189
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>  Labels: automation
>
> [Automation]Add hyper-v support for test_routers.py suite in BVT
> Few tests in test_routers.py suite file require ssh access to VR. Need to add 
> support for hyper-v similar to vmware in accessing VR via ssh.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-5910) mark the LDAP user as imported from LDAP

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi reassigned CLOUDSTACK-5910:
---

Assignee: Rajani Karuturi  (was: Demetrius Tsitrelis)

> mark the LDAP user as imported from LDAP
> 
>
> Key: CLOUDSTACK-5910
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5910
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>  Labels: ldap
> Fix For: 4.5.0
>
>
> currently once the ldap users are imported, there is no way to differentiate 
> between LDAP users and native cloudstack users. 
> There should be a way to differentiate these users so that the authentication 
> can differentiate between native and ldap users and only use the 
> corresponding authentication mechanism. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-4776) Add Automated integration tests for Netscaler support as external LB provider in VPC

[Sowmya Krishnan (JIRA)]

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

Sowmya Krishnan closed CLOUDSTACK-4776.
---


> Add Automated integration tests for Netscaler support as external LB provider 
> in VPC
> 
>
> Key: CLOUDSTACK-4776
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4776
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
>Reporter: Sowmya Krishnan
>Assignee: Sowmya Krishnan
>
> Tests to be added for support of Netscaler in VPC as external LB provider.
> Plan is to write tests will be created using ddt 
> (http://ddt.readthedocs.org/en/latest/example.html) so that new test scripts 
> need not be written but existing ones can be modified.
> This bug will be used for tracking all the tests related to this feature 
> automation
> Test case link is here: https://cwiki.apache.org/confluence/x/Ro-lAQ
> Feature description is here: https://cwiki.apache.org/confluence/x/bVzVAQ



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-4776) Add Automated integration tests for Netscaler support as external LB provider in VPC

[Sowmya Krishnan (JIRA)]

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

Sowmya Krishnan resolved CLOUDSTACK-4776.
-

Resolution: Fixed

> Add Automated integration tests for Netscaler support as external LB provider 
> in VPC
> 
>
> Key: CLOUDSTACK-4776
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4776
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
>Reporter: Sowmya Krishnan
>Assignee: Sowmya Krishnan
>
> Tests to be added for support of Netscaler in VPC as external LB provider.
> Plan is to write tests will be created using ddt 
> (http://ddt.readthedocs.org/en/latest/example.html) so that new test scripts 
> need not be written but existing ones can be modified.
> This bug will be used for tracking all the tests related to this feature 
> automation
> Test case link is here: https://cwiki.apache.org/confluence/x/Ro-lAQ
> Feature description is here: https://cwiki.apache.org/confluence/x/bVzVAQ



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7346) iSCSI primary storage test should be skipped on VMWare

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7346:
---

Fix Version/s: 4.5.0

BULK EDIT> Tagging for fixVersion 4.5. 

> iSCSI primary storage test should be skipped on VMWare
> --
>
> Key: CLOUDSTACK-7346
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7346
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Assignee: John Dilley
>Priority: Critical
> Fix For: 4.5.0
>
>
> As description - VMWare only supports VMFS which must be created in vCenter.
> We should create a smoke test for shared mount points (KVM), VMFS (VMWare) 
> and CIFS (Hyper-V) at some point, however given that no tests exist for the 
> other hypervisors yet, I'll postpone adding VMWare's primary storage test for 
> now.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7192) BVT tests which don't apply to Hyper-V should be skipped

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7192:
---

Fix Version/s: 4.5.0

BULK EDIT> Tagging for fixVersion 4.5. 

> BVT tests which don't apply to Hyper-V should be skipped
> 
>
> Key: CLOUDSTACK-7192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7192
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, marvin
>Affects Versions: 4.5.0
>Reporter: John Dilley
>Assignee: John Dilley
> Fix For: 4.5.0
>
>
> If a test is run through nose which doesn't apply to the hypervisor under 
> test, the test should be skipped.
> In particular, there are many Hyper-V tests which this applies to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7271) integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize fails on VMWare and Hyper-V

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7271:
---

Fix Version/s: 4.5.0

BULK EDIT> Tagging for fixVersion 4.5. 

> integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize
>  fails on VMWare and Hyper-V
> ---
>
> Key: CLOUDSTACK-7271
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7271
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, marvin
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Assignee: John Dilley
> Fix For: 4.5.0
>
>
> Testcase 
> integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize
>  fails on anything other than XenServer or KVM.
> This is because in non-KVM cases it looks for the error
> if "Hypervisor XenServer does not support rootdisksize override" in str(ex):
> Which is clearly not there if a hypervisor other than XenServer is used.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7354) [Automation] test_scale_vm fails with VMWare

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7354:
---

Fix Version/s: 4.5.0

BULK EDIT> Tagging for fixVersion 4.5. 

> [Automation] test_scale_vm fails with VMWare
> 
>
> Key: CLOUDSTACK-7354
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7354
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, VMware
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Assignee: John Dilley
> Fix For: 4.5.0
>
>
> test_scale_vm fails on VMWare, complaining about the lack of tools.
> The VM property needs to set isdynamicallyscalable to true, which the 
> testcase does, but unfortunately after the Scale VM command has been 
> attempted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7307) [Automation] Ability to instruct nosetests not to run tests which require the simulator

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7307:
---

Fix Version/s: 4.5.0

BULK EDIT> Tagging for fixVersion 4.5. 

> [Automation] Ability to instruct nosetests not to run tests which require the 
> simulator
> ---
>
> Key: CLOUDSTACK-7307
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7307
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Alex Brett
> Fix For: 4.5.0
>
>
> There are a number of Marvin tests which only work if using the simulator, an 
> example being test_deploy_vm_start_failure in 
> test/integration/smoke/misc/test_deploy_vm.py
> When running tests via nosetests, we currently use a combination of the 
> 'tags' and 'required_hardware' attributes to select the right tests to run. 
> For example a KVM advanced zone BVT would run nosetests with {{-a 
> tags=advanced}}, while a simulator test would do {{-a 
> tags=advanced,required_hardware=false}}.
> An attempt at solving this issue has been made by setting the 
> required_hardware attribute to "simulator only", e.g.:
> {noformat}
> @attr(tags = ['advanced'], required_hardware="simulator only")
> def test_deploy_vm_start_failure(self):
> {noformat}
> Unfortunately this is not practical from nosetests, as you can't do e.g. {{-a 
> required_hardware!='simulator only'}}, as nosetests does not support this. 
> The only way now to identify all appropriate tests would be to run it with 
> something like {{-a tags=advanced,!required_hardware -a 
> tags=advanced,required_hardware=false -a 
> tags=advanced,required_hardware=true}}. This is both confusing, and 
> potentially error prone as if someone adds an additional value to 
> required_hardware, nosetests will miss it.
> In theory it is possible to achieve something using the {{-A}} argument to 
> nosetests, however experimenting here shows that it would still end up being 
> very confusing.
> I believe the solution is to add a new attribute "simulator_only", at which 
> point a typical advanced zone BVT could be run with just {{-a 
> tags=advanced,!simulator_only}}.
> I've prepared a patch which adds this attribute.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7348:
---

Assignee: Bharat Kumar

> [Automation] InvalidParameter Exception with stacktrace in  MS log
> --
>
> Key: CLOUDSTACK-7348
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue observed during automation run, there are many InvalidParameter 
> Exception with stacktrace, this should be handled properly 
> 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END===  
> 10.223.240.194 -- GET
>   
> jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ&
> command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D
> 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while 
> executi
> ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin
> com.cloud.exception.InvalidParameterValueException: This operation not 
> permitted for this hypervisor of the vm
> at 
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339)
> at 
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328)
> at 
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source)
> at 
> org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at 
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> 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 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7349) [Automation] CloudRuntimeException with stacktrace in MS log

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-7349:
---

Assignee: Jayapal Reddy

> [Automation] CloudRuntimeException  with stacktrace in  MS log
> --
>
> Key: CLOUDSTACK-7349
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7349
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue observed during automation run, there are many InvalidParameter 
> Exception with stacktrace, this should be handled properly 
> 2014-08-14 00:34:16,190 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-96:ctx-7c9884ce job-6881) Unexpected exception while 
> executin
> g 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to add specified 
> loadbalancerruleid for vms [973]
> at 
> com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignToLoadBalancer(LoadBalancingRulesManagerImpl.java:1139)
> at sun.reflect.GeneratedMethodAccessor774.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy137.assignToLoadBalancer(Unknown Source)
> at 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd.execute(AssignToLoadBalancerRuleCmd.java:169)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at 
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> 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 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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:744)
> 2014-08-14 00:34:16,191 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-96:ctx-7c9884ce job-6881) Complete async job-6881, 
> jobStatus: FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
>  to add specified loadbalancerruleid for vms [973]"}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7231) [Automation] Vm migration test cases failing in simulator run

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan resolved CLOUDSTACK-7231.
-

Resolution: Fixed

Veirfied with latest result, it works 

> [Automation] Vm migration test cases failing in simulator run 
> --
>
> Key: CLOUDSTACK-7231
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7231
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: Simulator
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: simulator__Log_15627.zip
>
>
> Run the test case 
> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm from 
> simulator, Test cases failed with below error 
> Job failed: {jobprocstatus : 0, created : u'2014-08-01T20:21:16-0700', cmd : 
> u'org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd', userid : 
> u'744d896e-19f1-11e4-89a0-00163e0af42c', jobstatus : 2, jobid : 
> u'59de174c-18cf-4580-9614-419ba5c7ecd9', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Job failed due to 
> exception com.cloud.agent.api.Answer cannot be cast to 
> com.cloud.agent.api.CheckVirtualMachineAnswer'}, accountid : 
> u'744d629a-19f1-11e4-89a0-00163e0af42c'}
> See the attached logs 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7232) [Automation] test_vpc_remote_access_vpn failing Simulator runs

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi resolved CLOUDSTACK-7232.


Resolution: Fixed

> [Automation] test_vpc_remote_access_vpn failing Simulator runs 
> ---
>
> Key: CLOUDSTACK-7232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7232
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.5.0
> Environment: Simulator
>Reporter: Rayees Namathponnan
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: simulator__Log_15627.zip
>
>
> Run the test 
> integration.smoke.test_vpc_vpn.TestVpcRemoteAccessVpn.test_vpc_remote_access_vp
>  from simulator 
> Test failed with below error 
> Job failed: {jobprocstatus : 0, created : u'2014-08-01T20:19:19-0700', 
> jobresult : {errorcode : 530, errortext : u'Failed to create VPC'}, cmd : 
> u'org.apache.cloudstack.api.command.admin.vpc.CreateVPCCmdByAdmin', userid : 
> u'744d896e-19f1-11e4-89a0-00163e0af42c', jobstatus : 2, jobid : 
> u'71508975-f16f-418e-8648-bcc57bdd142b', jobresultcode : 530, jobresulttype : 
> u'object', jobinstancetype : u'None', accountid : 
> u'744d629a-19f1-11e4-89a0-00163e0af42c'}
> Please check attached logs 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7369) assignVirtualMachine API name not intuitive

[Nitin Mehta (JIRA)]

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

Nitin Mehta updated CLOUDSTACK-7369:


Description: 
I just went to a meetup and was talking to [~jlkinsel] who was talking about 
moving vms from one account to another and was doing it manually through a huge 
set of db queries. We already had this api in place since 3.0.x but folks are 
not aware of it due to unintuitive api name. I can think of 2 solutions at the 
moment.

1. Create another api say changeVmOwnership and internally point it to the same 
logic as assignVirtualMachine. Mark assignVirtualMachine as deprecated api name 
for 5.0
2. OR in the api documentation name it as changeVmOwnership so that folks would 
know such functionality exists and is available through APIs

  was:
I just went to a meetup and was talking to [~jlkinsel] who was talking about 
moving vms from one account to another and was doing it manually through a huge 
set of db queries. We already had this api in place since 3.0.x but folks are 
not aware of it due to unintuitive api name. I can think of 2 solutions at the 
moment.

1. Create another api say changeVmOwnership and internally point it to the same 
logic as assignVirtualMachine. Mark assignVirtualMachine as deprecated api name 
for 5.0
2. OR in the api documentation name it as changeVmOwnership so that folks would 
know what this is possible through APIs


> assignVirtualMachine API name not intuitive
> ---
>
> Key: CLOUDSTACK-7369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7369
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.5.0
>Reporter: Nitin Mehta
>Priority: Critical
> Fix For: 4.5.0
>
>
> I just went to a meetup and was talking to [~jlkinsel] who was talking about 
> moving vms from one account to another and was doing it manually through a 
> huge set of db queries. We already had this api in place since 3.0.x but 
> folks are not aware of it due to unintuitive api name. I can think of 2 
> solutions at the moment.
> 1. Create another api say changeVmOwnership and internally point it to the 
> same logic as assignVirtualMachine. Mark assignVirtualMachine as deprecated 
> api name for 5.0
> 2. OR in the api documentation name it as changeVmOwnership so that folks 
> would know such functionality exists and is available through APIs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7369) assignVirtualMachine API name not intuitive

[Nitin Mehta (JIRA)]

Nitin Mehta created CLOUDSTACK-7369:
---

 Summary: assignVirtualMachine API name not intuitive
 Key: CLOUDSTACK-7369
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7369
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.5.0
Reporter: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0


I just went to a meetup and was talking to [~jlkinsel] who was talking about 
moving vms from one account to another and was doing it manually through a huge 
set of db queries. We already had this api in place since 3.0.x but folks are 
not aware of it due to unintuitive api name. I can think of 2 solutions at the 
moment.

1. Create another api say changeVmOwnership and internally point it to the same 
logic as assignVirtualMachine. Mark assignVirtualMachine as deprecated api name 
for 5.0
2. OR in the api documentation name it as changeVmOwnership so that folks would 
know what this is possible through APIs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7351:


Assignee: Girish Shilamkar  (was: Rayees Namathponnan)

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7351:


Assignee: Rayees Namathponnan  (was: Girish Shilamkar)

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan commented on CLOUDSTACK-7351:
-

Thanks assigning to Girish 

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Harikrishna Patnala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7351:


Issue Type: Test  (was: Bug)

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7351:


Assignee: Girish Shilamkar  (was: Harikrishna Patnala)

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7368) [Automation] Fix the script "test_add_remove_network.py" - Accounts are not cleaned up during successful test execution

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7368:
-

Issue Type: Test  (was: Bug)

> [Automation] Fix the script "test_add_remove_network.py" - Accounts are not 
> cleaned up during successful test execution
> ---
>
> Key: CLOUDSTACK-7368
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7368
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Notice that the accounts are not cleaned up during successful test execution 
> in the script below.
> {Code}
> @attr(tags = ["advanced"])
> def test_24_add_nw_different_domain(self):
> """Add network to running VM"""
> # 1. Create two domains
> # 2. Create network in one domain and create virtual machine in other 
> domain
> # 3. Ad isolated/shared network belonging to one domain to the vm 
> belonging to other domain
> # Validate the following:
> # 1. Adding network should fail
> network = None #The network which we are adding to the vm
> try:
> tempCleanupList = []
> self.child_domain_1 = Domain.create(self.apiclient,
> services=self.services["domain"],
> parentdomainid=self.domain.id)
> tempCleanupList.append(self.child_domain_1)
> self.child_do_admin_1 = Account.create(
> self.apiclient,
> self.services["account"],
> admin=True,
> domainid=self.child_domain_1.id
> )
> tempCleanupList.append(self.child_do_admin_1)
> self.child_domain_2 = Domain.create(self.apiclient,
>   
> services=self.services["domain"],
>   parentdomainid=self.domain.id)
> tempCleanupList.append(self.child_domain_2)
> self.child_do_admin_2 = Account.create(
> self.apiclient,
> self.services["account"],
> admin=True,
> domainid=self.child_domain_2.id)
> tempCleanupList.append(self.child_do_admin_2)
> except Exception as e:
> tempCleanupList.reverse()
> self.cleanup += tempCleanupList
> self.fail(e)
> ## Notice that the Accounts are not added to cleanup list to get cleaned up 
> during successful test execution
> network = 
> Network.create(self.api_client,self.services["isolated_network"],self.child_do_admin_1.name,
>  
> self.child_do_admin_1.domainid,networkofferingid=self.isolated_network_offering.id)
> virtual_machine = VirtualMachine.create(self.apiclient, 
> self.services["virtual_machine"],accountid=self.child_do_admin_2.name,
> 
> domainid=self.child_do_admin_2.domainid, 
> serviceofferingid=self.service_offering.id,
> 
> mode=self.zone.networktype)
> time.sleep(self.services["sleep"])
> self.debug("Trying to %s network in domain %s to a vm in domain %s, 
> This should fail" %
>(network.type, self.child_domain_1.name, 
> self.child_domain_2.name))
> with self.assertRaises(Exception) as e:
> virtual_machine.add_nic(self.apiclient, network.id)
> self.debug("Operation failed with exception %s" % e.exception)
> return
> {Code}
> Due to the above mentioned bug, the follow error is seen:
> {Code}
> test_25_add_nw_above_account_limit 
> (test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: 
> Sending GET Cmd : deleteServiceOffering===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.130.79
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?response=json&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=deleteServiceOffering&id=d6397b91-56a8-4bbc-94ba-2fdbf7fb4582&signature=Y7VStlORyVL1MqIGfZxjvr30TJw%3D
>  HTTP/1.1" 200 60
> test_25_add_nw_above_account_limit 
> (test_add_remove_network.TestAddNetworkT

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Issue Type: Test  (was: Bug)

> [Automation] Fix the script "test_add_remove_network.py" - Listing VM after 
> VM's deletion doesnt show VM in the list
> 
>
> Key: CLOUDSTACK-7367
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7367
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Girish Shilamkar
> Fix For: 4.5.0
>
>
> *Test Client Error Stack Trace:*
> {code}
> ---
> FAIL: update default nic of vm when vm is state is not Running or Stopped
> ---
> Traceback (most recent call last):
>   File "/home/chandan/test_add_remove_network.py", line 1777, in 
> test_23_update_nic_incorrect_vm_state
> vm_list_validation_result[2])
> AssertionError: vm list validation failed due to INVALID INPUT
>  >> begin captured stdout << -
> === TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
> {code}
> *Root Cause Analysis:*
> *From the results log of Marvin Run, Observe "Response : None" for ListVMs 
> after VM's deletion:*
> {code}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Sending GET Cmd : queryAsyncJobResult===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.130.79
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
>  HTTP/1.1" 200 536
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', 
> jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []}, 
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', 
> userid : u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
> u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
> u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> ===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
> 2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', 
> jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []}, 
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', 
> userid : u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
> u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
> u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Payload: {'apiKey': 
> u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
>  'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 
> 'command': 'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Sending GET Cmd : listVirtualMachines===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.130.79
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
>  HTTP/1.1" 200 39
> test_23

[jira] [Updated] (CLOUDSTACK-7368) [Automation] Fix the script "test_add_remove_network.py" - Accounts are not cleaned up during successful test execution

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7368:
-

Description: 
Notice that the accounts are not cleaned up during successful test execution in 
the script below.

{Code}
@attr(tags = ["advanced"])
def test_24_add_nw_different_domain(self):
"""Add network to running VM"""

# 1. Create two domains
# 2. Create network in one domain and create virtual machine in other 
domain
# 3. Ad isolated/shared network belonging to one domain to the vm 
belonging to other domain

# Validate the following:
# 1. Adding network should fail

network = None #The network which we are adding to the vm

try:
tempCleanupList = []
self.child_domain_1 = Domain.create(self.apiclient,
services=self.services["domain"],
parentdomainid=self.domain.id)
tempCleanupList.append(self.child_domain_1)

self.child_do_admin_1 = Account.create(
self.apiclient,
self.services["account"],
admin=True,
domainid=self.child_domain_1.id
)
tempCleanupList.append(self.child_do_admin_1)

self.child_domain_2 = Domain.create(self.apiclient,
  services=self.services["domain"],
  parentdomainid=self.domain.id)
tempCleanupList.append(self.child_domain_2)

self.child_do_admin_2 = Account.create(
self.apiclient,
self.services["account"],
admin=True,
domainid=self.child_domain_2.id)
tempCleanupList.append(self.child_do_admin_2)
except Exception as e:
tempCleanupList.reverse()
self.cleanup += tempCleanupList
self.fail(e)
## Notice that the Accounts are not added to cleanup list to get cleaned up 
during successful test execution

network = 
Network.create(self.api_client,self.services["isolated_network"],self.child_do_admin_1.name,
 
self.child_do_admin_1.domainid,networkofferingid=self.isolated_network_offering.id)

virtual_machine = VirtualMachine.create(self.apiclient, 
self.services["virtual_machine"],accountid=self.child_do_admin_2.name,

domainid=self.child_do_admin_2.domainid, 
serviceofferingid=self.service_offering.id,
mode=self.zone.networktype)

time.sleep(self.services["sleep"])
self.debug("Trying to %s network in domain %s to a vm in domain %s, 
This should fail" %
   (network.type, self.child_domain_1.name, 
self.child_domain_2.name))

with self.assertRaises(Exception) as e:
virtual_machine.add_nic(self.apiclient, network.id)
self.debug("Operation failed with exception %s" % e.exception)
return

{Code}

Due to the above mentioned bug, the follow error is seen:

{Code}
test_25_add_nw_above_account_limit 
(test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: 
Sending GET Cmd : deleteServiceOffering===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?response=json&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=deleteServiceOffering&id=d6397b91-56a8-4bbc-94ba-2fdbf7fb4582&signature=Y7VStlORyVL1MqIGfZxjvr30TJw%3D
 HTTP/1.1" 200 60
test_25_add_nw_above_account_limit 
(test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: Response : 
{success : u'true'}
test_25_add_nw_above_account_limit 
(test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: Payload: 
{'signature': 'ObGqa7gqJ+rlKpv4gK66aoX8avk=', 'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'command': 'deleteNetworkOffering', 'id': 
u'e3a38505-c11d-41cf-b3ed-f0488d50149b', 'response': 'json'}
test_25_add_nw_above_account_limit 
(test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: 
Sending GET Cmd : deleteNetworkOffering===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?response=json&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=deleteNetworkOffering&id=e3

[jira] [Updated] (CLOUDSTACK-7368) [Automation] Fix the script "test_add_remove_network.py" - Accounts are not cleaned up during successful test execution

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7368:
-

Assignee: Gaurav Aradhye

> [Automation] Fix the script "test_add_remove_network.py" - Accounts are not 
> cleaned up during successful test execution
> ---
>
> Key: CLOUDSTACK-7368
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7368
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Notice that the accounts are not cleaned up during successful test execution 
> in the script below.
> {Code}
> @attr(tags = ["advanced"])
> def test_24_add_nw_different_domain(self):
> """Add network to running VM"""
> # 1. Create two domains
> # 2. Create network in one domain and create virtual machine in other 
> domain
> # 3. Ad isolated/shared network belonging to one domain to the vm 
> belonging to other domain
> # Validate the following:
> # 1. Adding network should fail
> network = None #The network which we are adding to the vm
> try:
> tempCleanupList = []
> self.child_domain_1 = Domain.create(self.apiclient,
> services=self.services["domain"],
> parentdomainid=self.domain.id)
> tempCleanupList.append(self.child_domain_1)
> self.child_do_admin_1 = Account.create(
> self.apiclient,
> self.services["account"],
> admin=True,
> domainid=self.child_domain_1.id
> )
> tempCleanupList.append(self.child_do_admin_1)
> self.child_domain_2 = Domain.create(self.apiclient,
>   
> services=self.services["domain"],
>   parentdomainid=self.domain.id)
> tempCleanupList.append(self.child_domain_2)
> self.child_do_admin_2 = Account.create(
> self.apiclient,
> self.services["account"],
> admin=True,
> domainid=self.child_domain_2.id)
> tempCleanupList.append(self.child_do_admin_2)
> except Exception as e:
> tempCleanupList.reverse()
> self.cleanup += tempCleanupList
> self.fail(e)
> ## Notice that the Accounts are not added to cleanup list to get cleaned up 
> during successful test execution
> network = 
> Network.create(self.api_client,self.services["isolated_network"],self.child_do_admin_1.name,
>  
> self.child_do_admin_1.domainid,networkofferingid=self.isolated_network_offering.id)
> virtual_machine = VirtualMachine.create(self.apiclient, 
> self.services["virtual_machine"],accountid=self.child_do_admin_2.name,
> 
> domainid=self.child_do_admin_2.domainid, 
> serviceofferingid=self.service_offering.id,
> 
> mode=self.zone.networktype)
> time.sleep(self.services["sleep"])
> self.debug("Trying to %s network in domain %s to a vm in domain %s, 
> This should fail" %
>(network.type, self.child_domain_1.name, 
> self.child_domain_2.name))
> with self.assertRaises(Exception) as e:
> virtual_machine.add_nic(self.apiclient, network.id)
> self.debug("Operation failed with exception %s" % e.exception)
> return
> {Code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7368) [Automation] Fix the script "test_add_remove_network.py" - Accounts are not cleaned up during successful test execution

[Chandan Purushothama (JIRA)]

Chandan Purushothama created CLOUDSTACK-7368:


 Summary: [Automation] Fix the script "test_add_remove_network.py" 
- Accounts are not cleaned up during successful test execution
 Key: CLOUDSTACK-7368
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7368
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


Notice that the accounts are not cleaned up during successful test execution in 
the script below.

{Code}
@attr(tags = ["advanced"])
def test_24_add_nw_different_domain(self):
"""Add network to running VM"""

# 1. Create two domains
# 2. Create network in one domain and create virtual machine in other 
domain
# 3. Ad isolated/shared network belonging to one domain to the vm 
belonging to other domain

# Validate the following:
# 1. Adding network should fail

network = None #The network which we are adding to the vm

try:
tempCleanupList = []
self.child_domain_1 = Domain.create(self.apiclient,
services=self.services["domain"],
parentdomainid=self.domain.id)
tempCleanupList.append(self.child_domain_1)

self.child_do_admin_1 = Account.create(
self.apiclient,
self.services["account"],
admin=True,
domainid=self.child_domain_1.id
)
tempCleanupList.append(self.child_do_admin_1)

self.child_domain_2 = Domain.create(self.apiclient,
  services=self.services["domain"],
  parentdomainid=self.domain.id)
tempCleanupList.append(self.child_domain_2)

self.child_do_admin_2 = Account.create(
self.apiclient,
self.services["account"],
admin=True,
domainid=self.child_domain_2.id)
tempCleanupList.append(self.child_do_admin_2)
except Exception as e:
tempCleanupList.reverse()
self.cleanup += tempCleanupList
self.fail(e)
## Notice that the Accounts are not added to cleanup list to get cleaned up 
during successful test execution

network = 
Network.create(self.api_client,self.services["isolated_network"],self.child_do_admin_1.name,
 
self.child_do_admin_1.domainid,networkofferingid=self.isolated_network_offering.id)

virtual_machine = VirtualMachine.create(self.apiclient, 
self.services["virtual_machine"],accountid=self.child_do_admin_2.name,

domainid=self.child_do_admin_2.domainid, 
serviceofferingid=self.service_offering.id,
mode=self.zone.networktype)

time.sleep(self.services["sleep"])
self.debug("Trying to %s network in domain %s to a vm in domain %s, 
This should fail" %
   (network.type, self.child_domain_1.name, 
self.child_domain_2.name))

with self.assertRaises(Exception) as e:
virtual_machine.add_nic(self.apiclient, network.id)
self.debug("Operation failed with exception %s" % e.exception)
return

{Code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7357) CLONE - Failed to stop VPC router with NPE

[Amogh Vasekar (JIRA)]

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

Amogh Vasekar resolved CLOUDSTACK-7357.
---

Resolution: Fixed

> CLONE - Failed to stop VPC router with NPE
> --
>
> Key: CLOUDSTACK-7357
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7357
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.0
>Reporter: Amogh Vasekar
>Assignee: Amogh Vasekar
>Priority: Blocker
> Fix For: 4.4.1
>
>
> There are many VPC router stop cases failing in automation runs,
> VPC router stop fails with below  NPE
> 2014-08-08 10:30:01,087 DEBUG [c.c.n.v.NetworkACLManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Applying NetworkACL for network: 369 with 
> Network ACL service provider
> 2014-08-08 10:30:01,090 DEBUG [c.c.n.e.VpcVirtualRouterElement] 
> (AccountChecker-1:ctx-13aaf529) Virtual router elemnt doesn't need to apply 
> firewall rules on the backend; virtual router doesn't exist in the network 369
> 2014-08-08 10:30:01,091 DEBUG [c.c.n.v.NetworkACLManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Successfully released Network ACLs for 
> network id=369 and # of rules now = 3
> 2014-08-08 10:30:01,092 DEBUG [c.c.n.r.RulesManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Found 0 static nat rules to apply for network 
> id 369
> 2014-08-08 10:30:01,098 DEBUG [c.c.n.e.VpcVirtualRouterElement] 
> (AccountChecker-1:ctx-13aaf529) VpcVirtualRouter element doesn't need to 
> associate ip addresses on the backend; VPC virtual router doesn't exist in 
> the network 369
> 2014-08-08 10:30:01,099 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (AccountChecker-1:ctx-13aaf529) Sending network shutdown to VpcVirtualRouter
> 2014-08-08 10:30:01,110 DEBUG [c.c.n.NetworkModelImpl] 
> (AccountChecker-1:ctx-13aaf529) Service SecurityGroup is not supported in the 
> network id=369
> 2014-08-08 10:30:01,110 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Router r-320-VM is in Stopped, so not sending 
> setup guest network command to the backend
> 2014-08-08 10:30:01,115 WARN  [o.a.c.e.o.NetworkOrchestrator] 
> (AccountChecker-1:ctx-13aaf529) Unable to complete shutdown of the network 
> elements due to element: VpcVirtualRouter
> java.lang.NullPointerException
> at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:63)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveVmFromNetwork(VirtualMachineManagerImpl.java:3024)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.removeVmFromNetwork(VirtualMachineManagerImpl.java:3009)
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.removeVpcRouterFromGuestNetwork(VpcVirtualNetworkApplianceManagerImpl.java:321)
> at sun.reflect.GeneratedMethodAccessor280.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy189.removeVpcRouterFromGuestNetwork(Unknown 
> Source)
> at 
> com.cloud.network.element.VpcVirtualRouterElement.shutdown(VpcVirtualRouterElement.java:261)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2142)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetwork(NetworkOrchestrator.java:2044)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2202)
> at 
> com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:793)
> at 
> com.cloud.user.AccountManagerImpl$AccountCleanupTask.runInContext(AccountManagerImpl.java:1675)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedC

[jira] [Resolved] (CLOUDSTACK-7356) CLONE - NPE XenServerGuru.java:95 when remove the nic from the vm in Stopped state

[Amogh Vasekar (JIRA)]

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

Amogh Vasekar resolved CLOUDSTACK-7356.
---

Resolution: Fixed

> CLONE - NPE XenServerGuru.java:95 when remove the nic from the vm in Stopped 
> state
> --
>
> Key: CLOUDSTACK-7356
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7356
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.4.0
>Reporter: Amogh Vasekar
>Assignee: Amogh Vasekar
>Priority: Critical
> Fix For: 4.4.1
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Steps to reproduce:
> 1) deploy vm with 1 network in Xen environment. Stop it
> 2) attach nic to the stopped vm from another network
> 3) Try to delete the nic. Following NPE happens:
> java.lang.NullPointerException
> at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:95)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:3554)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:5280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> 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 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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:744)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server

[Pierre-Luc Dion (JIRA)]

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

Pierre-Luc Dion commented on CLOUDSTACK-7365:
-

I'm not sure I understand the insert/update mentioned, as long as a missing 
templates cannot disallow management-server to start...

Thanks,

> Upgrading without proper systemvm template corrupt cloudstack management 
> server
> ---
>
> Key: CLOUDSTACK-7365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>  Labels: upgrade
> Attachments: 4.4.0to4.4.1_mgtlogissue.txt
>
>
> Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack 
> management server, it is required to have systemvm template properly named 
> prior to the upgrade. otherwise the management server will fail to restart 
> with after upgrading database schema.
> The possible repair method is to revert packages to previously installed 
> CloudStack and restore the database which have been upgraded.
> This is not a viable upgrade path since management servers packages could be 
> accidentally upgraded after a  "yum upgrade" or "apt-get update".
> Upgrading CloudStack management-server without previously uploading systemvm 
> template should not fail to start the management-server. if the systemvm 
> template is not in place, then the management-server cannot start.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7146) [Automation] Fix the scripts "test_assign_vm.py, test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py" - Cleanup of domain should be done after

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7146:
-

Description: 

*Error Messages:*

---
*One:*
---

{code}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Payload: 
{'signature': 'ctoosHX10fXC2XJv8iFdUiNqV5Q=', 'apiKey': 
u'K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'ebbf78c7-5a1d-4051-8404-26314a59151a'}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Sending 
GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.135.41
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=ctoosHX10fXC2XJv8iFdUiNqV5Q%3D&apiKey=K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA&command=queryAsyncJobResult&response=json&jobid=ebbf78c7-5a1d-4051-8404-26314a59151a
 HTTP/1.1" 200 477
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
{jobprocstatus : 0, created : u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): ERROR:  __poll: 
Exception Occurred :Job failed: {jobprocstatus : 0, created : 
u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'} 
Traceback (most recent call last):
  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
 line 105, in __poll
% async_response)
Exception: Job failed: {jobprocstatus : 0, created : 
u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : FAILED
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): ERROR: marvinRequest : 
CmdName:  Exception: ['Traceback (most recent call last):\n', '  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
 line 375, in marvinRequest\nraise self.__lastError\n', 'Exception: Job 
failed: {jobprocstatus : 0, created : u\'2014-07-11T16:11:24+\', cmd : 
u\'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd\', userid : 
u\'ce302410-0901-11e4-a9bc-5a9383355ca2\', jobstatus : 2, jobid : 
u\'ebbf78c7-5a1d-4051-8404-26314a59151a\', jobresultcode : 530, jobresulttype : 
u\'object\', jobresult : {errorcode : 530, errortext : u"Can\'t delete the 
domain yet because it has 1 accounts to cleanup"}, accountid : 
u\'ce30160a-0901-11e4-a9bc-5a9383355ca2\'}\n']
Traceback (most recent call last):
  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
 line 375, in marvinRequest
raise self.__lastError
Exception: Job failed: {jobprocstatus : 0, created : 
u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
test_16_move_across_subdomain_volume_and_account_l

[jira] [Updated] (CLOUDSTACK-7146) [Automation] Fix the scripts "test_assign_vm.py, test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py" - Cleanup of domain should be done after

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7146:
-

Description: 

*Error Messages:*

---
*One:*
---

{code}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Payload: 
{'signature': 'ctoosHX10fXC2XJv8iFdUiNqV5Q=', 'apiKey': 
u'K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'ebbf78c7-5a1d-4051-8404-26314a59151a'}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Sending 
GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.135.41
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=ctoosHX10fXC2XJv8iFdUiNqV5Q%3D&apiKey=K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA&command=queryAsyncJobResult&response=json&jobid=ebbf78c7-5a1d-4051-8404-26314a59151a
 HTTP/1.1" 200 477
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
{jobprocstatus : 0, created : u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): ERROR:  __poll: 
Exception Occurred :Job failed: {jobprocstatus : 0, created : 
u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'} 
Traceback (most recent call last):
  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
 line 105, in __poll
% async_response)
Exception: Job failed: {jobprocstatus : 0, created : 
u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : FAILED
test_16_move_across_subdomain_volume_and_account_limit 
(integration.component.test_assign_vm.TestVMOwnership): ERROR: marvinRequest : 
CmdName:  Exception: ['Traceback (most recent call last):\n', '  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
 line 375, in marvinRequest\nraise self.__lastError\n', 'Exception: Job 
failed: {jobprocstatus : 0, created : u\'2014-07-11T16:11:24+\', cmd : 
u\'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd\', userid : 
u\'ce302410-0901-11e4-a9bc-5a9383355ca2\', jobstatus : 2, jobid : 
u\'ebbf78c7-5a1d-4051-8404-26314a59151a\', jobresultcode : 530, jobresulttype : 
u\'object\', jobresult : {errorcode : 530, errortext : u"Can\'t delete the 
domain yet because it has 1 accounts to cleanup"}, accountid : 
u\'ce30160a-0901-11e4-a9bc-5a9383355ca2\'}\n']
Traceback (most recent call last):
  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
 line 375, in marvinRequest
raise self.__lastError
Exception: Job failed: {jobprocstatus : 0, created : 
u'2014-07-11T16:11:24+', cmd : 
u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete the domain 
yet because it has 1 accounts to cleanup"}, accountid : 
u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
test_16_move_across_subdomain_volume_and_account_l

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{code}
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
{code}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe "Response : None" for ListVMs 
after VM's deletion:*

{code}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionEr

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Assignee: Girish Shilamkar

> [Automation] Fix the script "test_add_remove_network.py" - Listing VM after 
> VM's deletion doesnt show VM in the list
> 
>
> Key: CLOUDSTACK-7367
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7367
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Girish Shilamkar
> Fix For: 4.5.0
>
>
> *Test Client Error Stack Trace:*
> {code}
> ---
> FAIL: update default nic of vm when vm is state is not Running or Stopped
> ---
> Traceback (most recent call last):
>   File "/home/chandan/test_add_remove_network.py", line 1777, in 
> test_23_update_nic_incorrect_vm_state
> vm_list_validation_result[2])
> AssertionError: vm list validation failed due to INVALID INPUT
>  >> begin captured stdout << -
> === TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
> {code}
> *Root Cause Analysis:*
> *From the results log of Marvin Run, Observe "Response : None" for ListVMs 
> after VM's deletion:*
> {code}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Sending GET Cmd : queryAsyncJobResult===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.130.79
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
>  HTTP/1.1" 200 536
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', 
> jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []}, 
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', 
> userid : u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
> u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
> u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> ===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
> 2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', 
> jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []}, 
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', 
> userid : u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
> u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
> u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Payload: {'apiKey': 
> u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
>  'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 
> 'command': 'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
> test_23_update_nic_incorrect_vm_state 
> (test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
> Sending GET Cmd : listVirtualMachines===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.130.79
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
>  HTTP/1.1" 200 39
> test_23_up

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{code}
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
{code}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe "Response : None" for ListVMs 
after VM's deletion:*

{code}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionEr

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{code}
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
{code}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe "Response : None" for ListVMs 
after VM's deletion:*

{code}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionEr

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{code}
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
{code}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe the highlighted line in the log:*

{code}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionError: vm list valida

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{code}
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
{code}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe "Response : None*" for ListVMs 
after VM's deletion:*

{code}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionE

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{code}
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
{code}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe the highlighted line in the log:*

{
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionError: vm list validation 

[jira] [Created] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

Chandan Purushothama created CLOUDSTACK-7367:


 Summary: [Automation] Fix the script "test_add_remove_network.py" 
- Listing VM after VM's deletion doesnt show VM in the list
 Key: CLOUDSTACK-7367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
 Fix For: 4.5.0




*Test Client Error Stack Trace:*

{
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe the highlighted line in the log:*

{
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py

[jira] [Updated] (CLOUDSTACK-7367) [Automation] Fix the script "test_add_remove_network.py" - Listing VM after VM's deletion doesnt show VM in the list

[Chandan Purushothama (JIRA)]

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

Chandan Purushothama updated CLOUDSTACK-7367:
-

Description: 
*Test Client Error Stack Trace:*

{{
---
FAIL: update default nic of vm when vm is state is not Running or Stopped
---
Traceback (most recent call last):
  File "/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state
vm_list_validation_result[2])
AssertionError: vm list validation failed due to INVALID INPUT
 >> begin captured stdout << -
=== TestName: test_23_update_nic_incorrect_vm_state | Status : FAILED ===
}}

*Root Cause Analysis:*

*From the results log of Marvin Run, Observe the highlighted line in the log:*

{
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?jobid=2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=queryAsyncJobResult&response=json&signature=FK3sso3aJJvft%2BLJUoqXGRwohAk%3D
 HTTP/1.1" 200 536
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
===Jobid:2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d ; StartTime:Tue Aug 12 18:40:12 
2014 ; EndTime:Tue Aug 12 18:41:08 2014 ; TotalTime:-55===
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : {jobprocstatus : 0, created : u'2014-08-12T19:01:14-0700', jobresult 
: {affinitygroup : [], nic : [], securitygroup : [], tags : []}, cmd : 
u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', userid : 
u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 1, jobid : 
u'2dabf6ab-e871-48ea-a6c8-ef1862dc4f5d', jobresultcode : 0, jobinstanceid : 
u'e6953bc0-14b0-4b01-8e10-9174964f4892', jobresulttype : u'object', 
jobinstancetype : u'VirtualMachine', accountid : 
u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Payload: {'apiKey': 
u'ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog',
 'id': u'e6953bc0-14b0-4b01-8e10-9174964f4892', 'response': 'json', 'command': 
'listVirtualMachines', 'signature': 'hBKJs25V40Y/ocF51bJ4MvRvEik='}
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.130.79
requests.packages.urllib3.connectionpool: DEBUG: "GET 
/client/api?signature=hBKJs25V40Y%2FocF51bJ4MvRvEik%3D&apiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqog&command=listVirtualMachines&id=e6953bc0-14b0-4b01-8e10-9174964f4892&response=json
 HTTP/1.1" 200 39
test_23_update_nic_incorrect_vm_state 
*(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): DEBUG: 
Response : None*
test_23_update_nic_incorrect_vm_state 
(test_add_remove_network.TestFailureScenariosUpdateVirtualMachineNIC): 
CRITICAL: FAILED: test_23_update_nic_incorrect_vm_state: ['Traceback (most 
recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
318, in run\ntestMethod()\n', '  File 
"/home/chandan/test_add_remove_network.py", line 1777, in 
test_23_update_nic_incorrect_vm_state\nvm_list_validation_result[2])\n', '  
File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionError: vm list validation failed 

[jira] [Commented] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

[ASF subversion and git services (JIRA)]

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

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

Commit 5a68f031ce3fe211dce2287d6ca67294e582b84f in cloudstack's branch 
refs/heads/4.4 from [~vbernat]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5a68f03 ]

CLOUDSTACK-7193: handle domain ID being an int

Recent versions of libvirt (at least 0.9.8) will return an int when
queried for the ID of a domain, not a string. This breaks some parts of
the `security_group.py` script which expects a string containing an
int. Notably, this breaks the part handling VM reboots which is
therefore not executed.

Signed-off-by: Vincent Bernat 
Signed-off-by: Sebastien Goasguen 


> Rebooting a VM doesn't update iptables rules
> 
>
> Key: CLOUDSTACK-7193
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.3.0
> Environment: Ubuntu Lucid 12.04 and more recent
>Reporter: Vincent Bernat
>
> Hi!
> Rebooting a VM doesn't update the iptables rules despite the change on the 
> interface name. To reproduce:
>  1. Starts two VM
>  2. Stop the first one.
>  3. Reboot the second one. It will use the vnet device of the first one.
>  4. Checks that the iptables rules for the second one are still referencing 
> the old interface.
> The defect seems to be in security_group.py. The periodic 
> "get_rule_logs_for_vm" which also handles rebooted VM fails because of the 
> following traceback:
> {code}
> 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
> Traceback (most recent call last):
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 705, in get_rule_logs_for_vms
> network_rules_for_rebooted_vm(name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 637, in network_rules_for_rebooted_vm
> [curr_domid, old_domid] = check_domid_changed(vm_name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 619, in check_domid_changed
> if (curr_domid is None) or (not curr_domid.isdigit()):
> AttributeError: 'int' object has no attribute 'isdigit'
> {code}
> This exception is catched by some try...except.
> On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
> I also checked that this is still the case with libvirt 1.2.4.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7295) [Automation] Failed to stop VPC router with NPE

[ASF subversion and git services (JIRA)]

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

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

Commit 9800b9f07a5b887da93661c12441e0d5f99fd717 in cloudstack's branch 
refs/heads/4.4 from [~amogh.vasekar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9800b9f ]

CLOUDSTACK-7295: VMs is Stopped state have no host ID, resulting in NPE


> [Automation] Failed to stop VPC router with NPE
> ---
>
> Key: CLOUDSTACK-7295
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7295
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Amogh Vasekar
>Priority: Blocker
> Fix For: 4.5.0
>
>
> There are many VPC router stop cases failing in automation runs,
> VPC router stop fails with below  NPE
> 2014-08-08 10:30:01,087 DEBUG [c.c.n.v.NetworkACLManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Applying NetworkACL for network: 369 with 
> Network ACL service provider
> 2014-08-08 10:30:01,090 DEBUG [c.c.n.e.VpcVirtualRouterElement] 
> (AccountChecker-1:ctx-13aaf529) Virtual router elemnt doesn't need to apply 
> firewall rules on the backend; virtual router doesn't exist in the network 369
> 2014-08-08 10:30:01,091 DEBUG [c.c.n.v.NetworkACLManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Successfully released Network ACLs for 
> network id=369 and # of rules now = 3
> 2014-08-08 10:30:01,092 DEBUG [c.c.n.r.RulesManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Found 0 static nat rules to apply for network 
> id 369
> 2014-08-08 10:30:01,098 DEBUG [c.c.n.e.VpcVirtualRouterElement] 
> (AccountChecker-1:ctx-13aaf529) VpcVirtualRouter element doesn't need to 
> associate ip addresses on the backend; VPC virtual router doesn't exist in 
> the network 369
> 2014-08-08 10:30:01,099 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (AccountChecker-1:ctx-13aaf529) Sending network shutdown to VpcVirtualRouter
> 2014-08-08 10:30:01,110 DEBUG [c.c.n.NetworkModelImpl] 
> (AccountChecker-1:ctx-13aaf529) Service SecurityGroup is not supported in the 
> network id=369
> 2014-08-08 10:30:01,110 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
> (AccountChecker-1:ctx-13aaf529) Router r-320-VM is in Stopped, so not sending 
> setup guest network command to the backend
> 2014-08-08 10:30:01,115 WARN  [o.a.c.e.o.NetworkOrchestrator] 
> (AccountChecker-1:ctx-13aaf529) Unable to complete shutdown of the network 
> elements due to element: VpcVirtualRouter
> java.lang.NullPointerException
> at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:63)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveVmFromNetwork(VirtualMachineManagerImpl.java:3024)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.removeVmFromNetwork(VirtualMachineManagerImpl.java:3009)
> at 
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.removeVpcRouterFromGuestNetwork(VpcVirtualNetworkApplianceManagerImpl.java:321)
> at sun.reflect.GeneratedMethodAccessor280.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy189.removeVpcRouterFromGuestNetwork(Unknown 
> Source)
> at 
> com.cloud.network.element.VpcVirtualRouterElement.shutdown(VpcVirtualRouterElement.java:261)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2142)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetwork(NetworkOrchestrator.java:2044)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2202)
> at 
> com.cloud.user.AccountManagerImpl.cleanu

[jira] [Commented] (CLOUDSTACK-7006) Template ID is missing in ROOT volume usages

[ASF subversion and git services (JIRA)]

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

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

Commit 23b8196445d962f15f97df03e8dac9ae0b80e56b in cloudstack's branch 
refs/heads/4.4 from [~olemasle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=23b8196 ]

CLOUDSTACK-7006: Restore template ID in ROOT volume usages

Signed-off-by: Sebastien Goasguen 


> Template ID is missing in ROOT volume usages
> 
>
> Key: CLOUDSTACK-7006
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7006
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Minor
> Fix For: 4.3.1
>
>
> In previous versions of CloudStack, the template ID was recorded for ROOT 
> volume usages, when the VM is created from a template.
> Since CloudStack 4.2, the template ID isn't recorded anymore, due to a 
> regression in the EVENT_VOLUME_CREATE event publishing:
> In commit 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=730d04508507409065a432e2aac931225947f268,
>  the last EVENT_VOLUME_CREATE misses the template id, that was previously 
> set. It seems a simple copy-paste error.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7366) Baremetal agent is not including in RPM spec file

[ASF subversion and git services (JIRA)]

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

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

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

CloudStackCLOUDSTACK-7366
Baremetal agent is not including in RPM spec file


> Baremetal agent is not including in RPM spec file
> -
>
> Key: CLOUDSTACK-7366
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7366
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Affects Versions: 4.5.0
>Reporter: frank zhang
>Assignee: frank zhang
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7366) Baremetal agent is not including in RPM spec file

[frank zhang (JIRA)]

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

frank zhang resolved CLOUDSTACK-7366.
-

Resolution: Fixed

> Baremetal agent is not including in RPM spec file
> -
>
> Key: CLOUDSTACK-7366
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7366
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Affects Versions: 4.5.0
>Reporter: frank zhang
>Assignee: frank zhang
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7366) Baremetal agent is not including in RPM spec file

[frank zhang (JIRA)]

frank zhang created CLOUDSTACK-7366:
---

 Summary: Baremetal agent is not including in RPM spec file
 Key: CLOUDSTACK-7366
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7366
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Packaging
Affects Versions: 4.5.0
Reporter: frank zhang
Assignee: frank zhang
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (CLOUDSTACK-7275) [Automation] NPE thrown in MS log while starting ConsoleProxy

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan reopened CLOUDSTACK-7275:
-


I dont have the steps to reproduce this issue, can you check why NPE from our 
code  ? we should be handled NPE in cloudstack code 

> [Automation] NPE thrown in MS log while starting ConsoleProxy
> -
>
> Key: CLOUDSTACK-7275
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7275
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: Aug_06_KVM.rar
>
>
> Below NPE  thrown in MS while starting Console Proxy
> {noformat}
> 2014-08-06 08:00:48,370 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Deplo
> ymentPlanningManagerImpl
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Clust
> eredVirtualMachineManagerImpl
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Netwo
> rkOrchestrator
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Downl
> oadListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
> DirectNetworkStatsListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
> UploadListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
> BehindOnPingListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
> ConsoleProxyListener
> 2014-08-06 08:00:48,442 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentManager-Handler-7:null) Ping from 3
> 2014-08-06 08:00:48,496 INFO  [c.c.c.ConsoleProxyManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Proxy 4 is no longer in DB, skip 
> sending startup command
> 2014-08-06 08:00:48,497 ERROR [c.c.c.AgentHookBase] 
> (AgentConnectTaskPool-66:ctx-277af113) Unexpected exception when sending http 
> handling startup command(time out) to the console proxy resource for proxy:4
> java.lang.NullPointerException
> at 
> com.cloud.consoleproxy.AgentHookBase.startAgentHttpHandlerInVM(AgentHookBase.java:212)
> at 
> com.cloud.consoleproxy.ConsoleProxyListener.processConnect(ConsoleProxyListener.java:71)
> at 
> com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:537)
> at 
> com.cloud.agent.manager.AgentManagerImpl.handleConnectedAgent(AgentManagerImpl.java:1030)
> at 
> com.cloud.agent.manager.AgentManagerImpl.access$000(AgentManagerImpl.java:119)
> at 
> com.cloud.agent.manager.AgentManagerImpl$HandleAgentConnectTask.runInContext(AgentManagerImpl.java:1114)
> 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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-08-06 08:00:48,497 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
> SshKeysDistriMonitor
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7349) [Automation] CloudRuntimeException with stacktrace in MS log

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7349:


Assignee: (was: Rayees Namathponnan)

> [Automation] CloudRuntimeException  with stacktrace in  MS log
> --
>
> Key: CLOUDSTACK-7349
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7349
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue observed during automation run, there are many InvalidParameter 
> Exception with stacktrace, this should be handled properly 
> 2014-08-14 00:34:16,190 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-96:ctx-7c9884ce job-6881) Unexpected exception while 
> executin
> g 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to add specified 
> loadbalancerruleid for vms [973]
> at 
> com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignToLoadBalancer(LoadBalancingRulesManagerImpl.java:1139)
> at sun.reflect.GeneratedMethodAccessor774.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy137.assignToLoadBalancer(Unknown Source)
> at 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd.execute(AssignToLoadBalancerRuleCmd.java:169)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at 
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> 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 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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:744)
> 2014-08-14 00:34:16,191 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-96:ctx-7c9884ce job-6881) Complete async job-6881, 
> jobStatus: FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
>  to add specified loadbalancerruleid for vms [973]"}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server

[Rohit Yadav (JIRA)]

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

Rohit Yadav commented on CLOUDSTACK-7365:
-

In the upgrade path what if we set a insert/update statement, will that solve?

> Upgrading without proper systemvm template corrupt cloudstack management 
> server
> ---
>
> Key: CLOUDSTACK-7365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>  Labels: upgrade
> Attachments: 4.4.0to4.4.1_mgtlogissue.txt
>
>
> Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack 
> management server, it is required to have systemvm template properly named 
> prior to the upgrade. otherwise the management server will fail to restart 
> with after upgrading database schema.
> The possible repair method is to revert packages to previously installed 
> CloudStack and restore the database which have been upgraded.
> This is not a viable upgrade path since management servers packages could be 
> accidentally upgraded after a  "yum upgrade" or "apt-get update".
> Upgrading CloudStack management-server without previously uploading systemvm 
> template should not fail to start the management-server. if the systemvm 
> template is not in place, then the management-server cannot start.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7280) Add support for xenserver 6.5

[Anthony Xu (JIRA)]

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

Anthony Xu resolved CLOUDSTACK-7280.


Resolution: Fixed

commit 2be02d1f515d8d089b6596127614fe6b8030d723
Author: Anthony Xu 
Date:   Fri Aug 15 11:43:14 2014 -0700

added XS 6.5 beta1 support, will change the version after XS 6.5 is released



> Add support for xenserver 6.5
> -
>
> Key: CLOUDSTACK-7280
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7280
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, Management Server
>Affects Versions: 4.5.0
> Environment: Xenserver : 6.5  with vGPU drivers
> CS : 4.5.0
>Reporter: Abhinav Roy
>Assignee: Anthony Xu
>Priority: Blocker
> Fix For: 4.5.0
>
>
> I am not able to add XEN 6.5 in my CS 4.5.0 setup. It says that the xenserver 
> version is not supported. 
> 014-08-07 15:22:36,082 DEBUG [c.c.h.x.d.XcpServerDiscoverer] 
> (catalina-exec-1:ctx-0286b366 ctx-24e71e8e) other exceptions: 
> java.lang.RuntimeException: Only support XCP 1.0.0, 1.1.0, 1.4.x, 1.5 beta, 
> 1.6.x; XenServer 5.6,  XenServer 5.6 FP1, XenServer 5.6 SP2, Xenserver 6.0, 
> 6.0.2, 6.1.0, 6.2.0 but this one is XenServer 6.4.93
> java.lang.RuntimeException: Only support XCP 1.0.0, 1.1.0, 1.4.x, 1.5 beta, 
> 1.6.x; XenServer 5.6,  XenServer 5.6 FP1, XenServer 5.6 SP2, Xenserver 6.0, 
> 6.0.2, 6.1.0, 6.2.0 .
> Please add support for this version as it is blocking my vGPU testing.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-5981) [Automation] Test case test_01_volume_from_snapshot failing while checking content

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan closed CLOUDSTACK-5981.
---

Resolution: Fixed

This failure not observed in 4.5

> [Automation] Test case test_01_volume_from_snapshot failing while checking 
> content 
> ---
>
> Key: CLOUDSTACK-5981
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5981
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.4.0
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.4.0
>
>
> Below test case always failing in vmware
> integration.component.test_snapshots.TestSnapshots.test_01_volume_from_snapshot
> observed below error in log
> paramiko.transport: DEBUG: [chan 5] Max packet out: 32768 bytes
> paramiko.transport: INFO: Secsh channel 5 opened.
> paramiko.transport: DEBUG: [chan 5] Sesch channel 5 request ok
> paramiko.transport: DEBUG: [chan 5] EOF received (5)
> paramiko.transport: DEBUG: [chan 5] EOF sent (5)
> sshClient: DEBUG: {Cmd: cat /mnt/tmp/test/test2/random.data via Host: 
> 10.223.243.36} {returns: ['cat: /mnt/tmp/test/test2/random.data: No such file 
> or directory']}
> test_01_volume_from_snapshot 
> (integration.component.test_snapshots.TestSnapshots): DEBUG: returned_data_0: 
> cat: /mnt/tmp/test/test1/random.data: No such file or directory
> test_01_volume_from_snapshot 
> (integration.component.test_snapshots.TestSnapshots): DEBUG: returned_data_1: 
> cat: /mnt/tmp/test/test2/random.data: No such file or directory
> test_01_volume_from_snapshot 
> (integration.component.test_snapshots.TestSnapshots): CRITICAL: FAILED: 
> test_01_volume_from_snapshot: Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py", 
> line 520, in test_01_volume_from_snapshot
> "Verify newly attached volume contents with existing one"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> AssertionError: Verify newly attached volume contents with existing one
> - >> end captured logging << -
> Stacktrace
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py", 
> line 520, in test_01_volume_from_snapshot
> "Verify newly attached volume contents with existing one"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> Verify newly attached volume contents with existing one
>  >> begin captured logging << 
> test_05_snapshot_events 
> (integration.component.test_snapshots.TestSnapshotEvents): DEBUG: sending GET 
> request: deleteServiceOffering {'id': u'fb02efa2-7284-463a-9393-27564de948e4'}
> test_05_snapshot_events 
> (integration.component.test_snapshots.TestSnapshotEvents): DEBUG: Computed 
> Signature by Marvin: VIAVY2npT1ST2Jtu7ADQERxVxGQ=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.49.197



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-5348) [Automation] Disabled test cases from test_egress_fw_rules.py need to be enabled

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-5348:


Fix Version/s: 4.5.0

> [Automation] Disabled test cases from test_egress_fw_rules.py need to be 
> enabled 
> -
>
> Key: CLOUDSTACK-5348
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5348
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.5.0
>
>
> There are 4 test cases disabled in test_egress_fw_rules.py, this defect 
> created to track this; 
> def test_05_egress_fr5(self):
> def test_05_1_egress_fr5(self):
> def test_08_egress_fr8(self):
> def test_08_1_egress_fr8(self):



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-5348) [Automation] Disabled test cases from test_egress_fw_rules.py need to be enabled

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-5348:


Affects Version/s: 4.5.0

> [Automation] Disabled test cases from test_egress_fw_rules.py need to be 
> enabled 
> -
>
> Key: CLOUDSTACK-5348
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5348
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.5.0
>
>
> There are 4 test cases disabled in test_egress_fw_rules.py, this defect 
> created to track this; 
> def test_05_egress_fr5(self):
> def test_05_1_egress_fr5(self):
> def test_08_egress_fr8(self):
> def test_08_1_egress_fr8(self):



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-3452) [Automation] Basic zone test cases failed to connect VM trough ssh

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan resolved CLOUDSTACK-3452.
-

Resolution: Fixed

This is not happening latest runs 

> [Automation] Basic zone test cases failed to connect VM trough ssh 
> ---
>
> Key: CLOUDSTACK-3452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0, 4.4.0
> Environment: Basic zone KVM 
>Reporter: Rayees Namathponnan
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.4.0, 4.2.0
>
>
> Below test cases failed to connect VM trough SSH, in basic we need to set 
> ingress rule to connect the vm from outside
> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
> integration.smoke.test_volumes.TestVolumes.test_02_attach_volume
> integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_vm_life_cycle.py", 
> line 748, in test_10_attachAndDetach_iso
> (self.virtual_machine.ipaddress, e))
>   File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> SSH failed for virtual machine: 10.223.250.234 - [Errno 110] Connection timed 
> out



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-3452) [Automation] Basic zone test cases failed to connect VM trough ssh

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan closed CLOUDSTACK-3452.
---


> [Automation] Basic zone test cases failed to connect VM trough ssh 
> ---
>
> Key: CLOUDSTACK-3452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0, 4.4.0
> Environment: Basic zone KVM 
>Reporter: Rayees Namathponnan
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.2.0, 4.4.0
>
>
> Below test cases failed to connect VM trough SSH, in basic we need to set 
> ingress rule to connect the vm from outside
> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
> integration.smoke.test_volumes.TestVolumes.test_02_attach_volume
> integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_vm_life_cycle.py", 
> line 748, in test_10_attachAndDetach_iso
> (self.virtual_machine.ipaddress, e))
>   File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> SSH failed for virtual machine: 10.223.250.234 - [Errno 110] Connection timed 
> out



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it

[Francois Gaudreault (JIRA)]

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

Francois Gaudreault updated CLOUDSTACK-7364:


Attachment: management-server.log.debug.gz

Management Server Log

> NetScaler won't create the Public VLAN and Bind the IP to it
> 
>
> Key: CLOUDSTACK-7364
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Francois Gaudreault
>Priority: Critical
> Attachments: management-server.log.debug.gz
>
>
> When adding a Load Balancing rule with the NetScaler, the provider will tag 
> and bind the private IP to the appropriate interface. However, the behaviour 
> for the Public Interface is different. It simply adds the IP untagged on all 
> interfaces. This is wrong.
> The public VLAN should be tagged, and the VIP bound to the right VLAN tag to 
> avoid unnecessary ARP on other VLANs.
> NS Version tested: 123,11, 127.10, 128.8



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log

[Rayees Namathponnan (JIRA)]

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

Rayees Namathponnan updated CLOUDSTACK-7348:


Summary: [Automation] InvalidParameter Exception with stacktrace in  MS log 
 (was: [Automatiion] InvalidParameter Exception with stacktrace in  MS log)

> [Automation] InvalidParameter Exception with stacktrace in  MS log
> --
>
> Key: CLOUDSTACK-7348
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue observed during automation run, there are many InvalidParameter 
> Exception with stacktrace, this should be handled properly 
> 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END===  
> 10.223.240.194 -- GET
>   
> jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ&
> command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D
> 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while 
> executi
> ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin
> com.cloud.exception.InvalidParameterValueException: This operation not 
> permitted for this hypervisor of the vm
> at 
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339)
> at 
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328)
> at 
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source)
> at 
> org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at 
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> 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 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)



--
This message was sent by Atla

[jira] [Commented] (CLOUDSTACK-7363) [Automation] test_vmware_drs should skip on non-VMWare Hypervisors

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7363 test_vmware_drs.py should skip on non-VMWare hypervisors

Make the tests check if the hypervisor being used is VMWare, and skip if not

Signed-off-by: Santhosh Edukulla 


> [Automation] test_vmware_drs should skip on non-VMWare Hypervisors
> --
>
> Key: CLOUDSTACK-7363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7363
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Alex Brett
>Assignee: Alex Brett
> Fix For: 4.5.0
>
>
> test/integration/component/test_vmware_drs.py is testing pure VMWare 
> features, so is only valid if run on VMWare hosts, however it currently 
> doesn't check this.
> It should test the hypervisor type and skip if a non-VMWare hypervisor is in 
> use.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7363) [Automation] test_vmware_drs should skip on non-VMWare Hypervisors

[Alex Brett (JIRA)]

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

Alex Brett commented on CLOUDSTACK-7363:


Review https://reviews.apache.org/r/24805 filed

> [Automation] test_vmware_drs should skip on non-VMWare Hypervisors
> --
>
> Key: CLOUDSTACK-7363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7363
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Alex Brett
>Assignee: Alex Brett
> Fix For: 4.5.0
>
>
> test/integration/component/test_vmware_drs.py is testing pure VMWare 
> features, so is only valid if run on VMWare hosts, however it currently 
> doesn't check this.
> It should test the hypervisor type and skip if a non-VMWare hypervisor is in 
> use.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it

[Francois Gaudreault (JIRA)]

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

Francois Gaudreault commented on CLOUDSTACK-7364:
-

Hi Rajesh,

You need the logs from ACS, NS or both? ;)

> NetScaler won't create the Public VLAN and Bind the IP to it
> 
>
> Key: CLOUDSTACK-7364
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Francois Gaudreault
>Priority: Critical
>
> When adding a Load Balancing rule with the NetScaler, the provider will tag 
> and bind the private IP to the appropriate interface. However, the behaviour 
> for the Public Interface is different. It simply adds the IP untagged on all 
> interfaces. This is wrong.
> The public VLAN should be tagged, and the VIP bound to the right VLAN tag to 
> avoid unnecessary ARP on other VLANs.
> NS Version tested: 123,11, 127.10, 128.8



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it

[Rajesh Battala (JIRA)]

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

Rajesh Battala commented on CLOUDSTACK-7364:


can you post the log/ info about the same?

> NetScaler won't create the Public VLAN and Bind the IP to it
> 
>
> Key: CLOUDSTACK-7364
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Francois Gaudreault
>Priority: Critical
>
> When adding a Load Balancing rule with the NetScaler, the provider will tag 
> and bind the private IP to the appropriate interface. However, the behaviour 
> for the Public Interface is different. It simply adds the IP untagged on all 
> interfaces. This is wrong.
> The public VLAN should be tagged, and the VIP bound to the right VLAN tag to 
> avoid unnecessary ARP on other VLANs.
> NS Version tested: 123,11, 127.10, 128.8



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server

[Pierre-Luc Dion (JIRA)]

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

Pierre-Luc Dion updated CLOUDSTACK-7365:


Attachment: 4.4.0to4.4.1_mgtlogissue.txt

Post upgrade management-server.log.

> Upgrading without proper systemvm template corrupt cloudstack management 
> server
> ---
>
> Key: CLOUDSTACK-7365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>  Labels: upgrade
> Attachments: 4.4.0to4.4.1_mgtlogissue.txt
>
>
> Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack 
> management server, it is required to have systemvm template properly named 
> prior to the upgrade. otherwise the management server will fail to restart 
> with after upgrading database schema.
> The possible repair method is to revert packages to previously installed 
> CloudStack and restore the database which have been upgraded.
> This is not a viable upgrade path since management servers packages could be 
> accidentally upgraded after a  "yum upgrade" or "apt-get update".
> Upgrading CloudStack management-server without previously uploading systemvm 
> template should not fail to start the management-server. if the systemvm 
> template is not in place, then the management-server cannot start.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server

[Pierre-Luc Dion (JIRA)]

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

Pierre-Luc Dion updated CLOUDSTACK-7365:


Affects Version/s: 4.4.0
   Labels: upgrade  (was: )

> Upgrading without proper systemvm template corrupt cloudstack management 
> server
> ---
>
> Key: CLOUDSTACK-7365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>  Labels: upgrade
>
> Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack 
> management server, it is required to have systemvm template properly named 
> prior to the upgrade. otherwise the management server will fail to restart 
> with after upgrading database schema.
> The possible repair method is to revert packages to previously installed 
> CloudStack and restore the database which have been upgraded.
> This is not a viable upgrade path since management servers packages could be 
> accidentally upgraded after a  "yum upgrade" or "apt-get update".
> Upgrading CloudStack management-server without previously uploading systemvm 
> template should not fail to start the management-server. if the systemvm 
> template is not in place, then the management-server cannot start.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server

[Pierre-Luc Dion (JIRA)]

Pierre-Luc Dion created CLOUDSTACK-7365:
---

 Summary: Upgrading without proper systemvm template corrupt 
cloudstack management server
 Key: CLOUDSTACK-7365
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.3.0, 4.4.1
Reporter: Pierre-Luc Dion


Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack 
management server, it is required to have systemvm template properly named 
prior to the upgrade. otherwise the management server will fail to restart with 
after upgrading database schema.

The possible repair method is to revert packages to previously installed 
CloudStack and restore the database which have been upgraded.

This is not a viable upgrade path since management servers packages could be 
accidentally upgraded after a  "yum upgrade" or "apt-get update".

Upgrading CloudStack management-server without previously uploading systemvm 
template should not fail to start the management-server. if the systemvm 
template is not in place, then the management-server cannot start.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6409) Upgrade from 4.2.1 to 4.3.0 failed due to database upgrade script

[Pierre-Luc Dion (JIRA)]

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

Pierre-Luc Dion commented on CLOUDSTACK-6409:
-

Could it be possible this issue has been resolved ?

> Upgrade from 4.2.1 to 4.3.0 failed due to database upgrade script
> -
>
> Key: CLOUDSTACK-6409
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6409
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.3.0
> Environment: CentOS 6.4, MySQL
>Reporter: Yong Chen
>  Labels: patch
>
> Upgrade failed due to SQL upgrade script for 421-to-430 tries to add many 
> columns and tables that are exist already in 4.2.1. 
> Tried to modify DB manually (see below SQL commands) to satisfy the upgrade 
> script. However it seems there are a lot more than a few. This upgrade script 
> needs to be reviewed to be able to detect existence of columns and tables or 
> remove them if needed rather than fail.
> ALTER TABLE async_job CHANGE related session_key INT;
> ALTER TABLE async_job ADD job_cmd_originator INT;
> ALTER TABLE async_job ADD callback_type INT;
> ALTER TABLE async_job ADD callback_address INT;
> ALTER TABLE async_job DROP job_type;
> ALTER TABLE async_job DROP job_dispatcher;
> ALTER TABLE async_job DROP job_executing_msid;
> ALTER TABLE async_job DROP job_pending_signals;
> ALTER TABLE network_offerings DROP keep_alive_enabled;
> ALTER TABLE vm_instance DROP power_state;
> ALTER TABLE vm_instance DROP power_state_update_time;
> ALTER TABLE vm_instance DROP power_state_update_count;
> ALTER TABLE vm_instance DROP FOREIGN KEY fk_vm_instance__power_host;
> ALTER TABLE vm_instance DROP power_host;
> ALTER TABLE load_balancing_rules DROP lb_protocol;
> DROP TABLE vm_work_job;
> DROP TABLE async_job_journal;
> DROP TABLE async_job_join_map;
> ALTER TABLE configuration DROP default_value;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it

[Francois Gaudreault (JIRA)]

Francois Gaudreault created CLOUDSTACK-7364:
---

 Summary: NetScaler won't create the Public VLAN and Bind the IP to 
it
 Key: CLOUDSTACK-7364
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.3.0, 4.4.0, 4.4.1
Reporter: Francois Gaudreault
Priority: Critical


When adding a Load Balancing rule with the NetScaler, the provider will tag and 
bind the private IP to the appropriate interface. However, the behaviour for 
the Public Interface is different. It simply adds the IP untagged on all 
interfaces. This is wrong.

The public VLAN should be tagged, and the VIP bound to the right VLAN tag to 
avoid unnecessary ARP on other VLANs.

NS Version tested: 123,11, 127.10, 128.8



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-5762) [dynamic compute offerings]UI change required for select compute offerinngs in add instance wizard

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-5762:
---

Priority: Trivial  (was: Major)

> [dynamic compute offerings]UI change required for select  compute offerinngs 
> in add instance wizard
> ---
>
> Key: CLOUDSTACK-5762
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5762
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: prashant kumar mishra
>Assignee: Jessica Wang
>Priority: Trivial
> Fix For: 4.4.0
>
> Attachments: screenshot-1.jpg
>
>
> "required" is overlapping on memory and cpu if dynamic compute offering 
> selected in deploy vm wizard .please check screenshot
> Steps to repro
> ===
> 1-preapare a  CS 4.3 setup
> 2-check select  compute offering page in deploy vm wizard.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-5550) UI - Api key and secret key not fully visible in user detail view.

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-5550:
---

Assignee: Gabor Apati-Nagy  (was: Jessica Wang)

> UI - Api key and secret key not fully visible in user detail view.
> --
>
> Key: CLOUDSTACK-5550
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5550
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: Gabor Apati-Nagy
> Fix For: 4.4.0
>
> Attachments: api-key.png, secret-key.png
>
>
> UI - Api key and secret key not fully visible in user detail view.
> Steps to reproduce the problem:
> Go to Accounts->select any account and use "View users". 
> Select any user and generate keys.
> Notice that "api key" and "secret key" get truncated in the user detail view.
> Attaching screenshots:



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-5550) UI - Api key and secret key not fully visible in user detail view.

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-5550:
---

Priority: Minor  (was: Major)

> UI - Api key and secret key not fully visible in user detail view.
> --
>
> Key: CLOUDSTACK-5550
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5550
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: Gabor Apati-Nagy
>Priority: Minor
> Fix For: 4.4.0
>
> Attachments: api-key.png, secret-key.png
>
>
> UI - Api key and secret key not fully visible in user detail view.
> Steps to reproduce the problem:
> Go to Accounts->select any account and use "View users". 
> Select any user and generate keys.
> Notice that "api key" and "secret key" get truncated in the user detail view.
> Attaching screenshots:



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-5576:
---

Priority: Minor  (was: Major)

> RemoteVPNonVPC :  Label needs to be changed to "Enable Remote Access VPN"
> -
>
> Key: CLOUDSTACK-5576
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Chandan Purushothama
>Assignee: Jessica Wang
>Priority: Minor
> Fix For: 4.4.0
>
> Attachments: UICapture38.png
>
>
> The corresponding UI Screenshot has been attached to the bug report.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-5550) UI - Api key and secret key not fully visible in user detail view.

[Stephen Turner (JIRA)]

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

Stephen Turner commented on CLOUDSTACK-5550:


Gabor, did your recent change to add Copy fix this?

> UI - Api key and secret key not fully visible in user detail view.
> --
>
> Key: CLOUDSTACK-5550
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5550
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: Gabor Apati-Nagy
> Fix For: 4.4.0
>
> Attachments: api-key.png, secret-key.png
>
>
> UI - Api key and secret key not fully visible in user detail view.
> Steps to reproduce the problem:
> Go to Accounts->select any account and use "View users". 
> Select any user and generate keys.
> Notice that "api key" and "secret key" get truncated in the user detail view.
> Attaching screenshots:



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-4644) Tool Tip information is not provided for the new fields which are added in 4.2 ( Ex: Register Template , Compute Offering, Network Offering UI )

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-4644:
---

Priority: Minor  (was: Major)

> Tool Tip information is not provided for the new fields which are added in 
> 4.2 ( Ex: Register Template , Compute Offering, Network Offering UI )
> 
>
> Key: CLOUDSTACK-4644
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4644
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Jessica Tomechak
>Priority: Minor
> Fix For: 4.4.0
>
>
> Observation: 
> Tool Tip information is not provided for the new fields which are added in 
> 4.2 ( Ex: Register Template , Compute Offering, Network Offering UI )
> 1. Register Template UI  :
> New Fields are : Dynamically Scalable , Routing  - There is no quick info 
> provided for these 
> 2. Create Compute Offering UI :  isVolatile , Deployment Planner, Planner 
> mode 
> 3. Create Network Offering UI :  Persistent , Default egress policy 
> 4. Add Affinity Groups  : Name, Description 
> 5. Add Guest Network : Secondary Isolated VLAN ID:
> 6. Add Region : id, name, end point 
> 7. Configure LDAP : All the fields, Except query filter 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-3212) [Advanced_With_SG]View IP Address Range in Default Guest Network page does not show the gateway and netmask for the IP Range

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-3212:
---

Issue Type: New Feature  (was: Bug)

> [Advanced_With_SG]View IP Address Range in Default Guest Network page does 
> not show the gateway and netmask for the IP Range
> 
>
> Key: CLOUDSTACK-3212
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3212
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: Latest build from master-6-17-stable branch
>Reporter: Sanjeev N
> Fix For: 4.4.0
>
> Attachments: listIPRange.JPG
>
>
> From 4.2 onwards we will be supporting multiple subnets per vlan for guest 
> Traffic. So admin can add multiple subnets/CIDRs in a single vlan. With 
> current implementation listing IP Ranges in a givin defaultguestnetwork only 
> shows the start ip and end ip of that ip range in UI, but it should also show 
> the gateway and netmask because there can be multiple CIDRs per vlan and each 
> CIDR can have seperate gateway and netmask.
> However listVlanIPRanges API shows all the information related to the CIDR. 
> API Fired:
> http://10.147.59.119:8080/client/api?command=listVlanIpRanges&zoneid=957f320c-767a-40ae-b0df-adeacd61ffcd&networkid=e2db33a4-5092-433f-8d33-2d3202a02d86&page=1&pagesize=20&response=json&sessionkey=6XgHLEak6xW8jvOciXszQAqwvEQ%3D&_=1372246636649
> Response:
> { "listvlaniprangesresponse" : { "count":3 ,"vlaniprange" : [  
> {"id":"a8fdaa6e-ed62-4e35-9235-7652c9ea113c","forvirtualnetwork":false,"zoneid":"957f320c-767a-40ae-b0df-adeacd61ffcd","vlan":"33","account":"system","domainid":"759d3732-dd7b-11e2-9424-06ab465f","domain":"ROOT","gateway":"10.147.33.1","netmask":"255.255.255.128","startip":"10.147.33.3","endip":"10.147.33.9","networkid":"e2db33a4-5092-433f-8d33-2d3202a02d86","physicalnetworkid":"1846c30d-96f7-4a00-8697-5cd76f2c249c"},
>  
> {"id":"668c33f3-9d14-4fe0-9e08-11eb79d9ba85","forvirtualnetwork":false,"zoneid":"957f320c-767a-40ae-b0df-adeacd61ffcd","vlan":"33","account":"system","domainid":"759d3732-dd7b-11e2-9424-06ab465f","domain":"ROOT","gateway":"10.147.33.129","netmask":"255.255.255.192","startip":"10.147.33.130","endip":"10.147.33.134","networkid":"e2db33a4-5092-433f-8d33-2d3202a02d86","physicalnetworkid":"1846c30d-96f7-4a00-8697-5cd76f2c249c"},
>  
> {"id":"8f0e87cf-4977-4f0b-a62e-3b0b85eaafc6","forvirtualnetwork":false,"zoneid":"957f320c-767a-40ae-b0df-adeacd61ffcd","vlan":"33","account":"system","domainid":"759d3732-dd7b-11e2-9424-06ab465f","domain":"ROOT","gateway":"10.147.33.129","netmask":"255.255.255.192","startip":"10.147.33.140","endip":"10.147.33.144","networkid":"e2db33a4-5092-433f-8d33-2d3202a02d86","physicalnetworkid":"1846c30d-96f7-4a00-8697-5cd76f2c249c"}
>  ] } }
> Attached screen shot shows the existing behavior. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-2026) IPV6 - UI - Provide the ability to turn off all the IPV6 parameters by using a global environment variables.

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-2026:
---

Component/s: (was: UI)

> IPV6 - UI - Provide the ability to turn off all the IPV6 parameters by using 
> a global environment variables.
> 
>
> Key: CLOUDSTACK-2026
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2026
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
> Environment: Build from master
>Reporter: Sangeetha Hariharan
> Fix For: 4.4.0
>
>
> IPV6 - UI - Provide the ability to turn off all the IPV6 parameters by using 
> a global environment variables.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6148) UI for feature "Use Secondary IP Address of NIC in load balancing"

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-6148:
---

Issue Type: New Feature  (was: Bug)

> UI for feature "Use Secondary IP Address of NIC in load balancing"
> --
>
> Key: CLOUDSTACK-6148
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6148
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Brian Federle
> Fix For: 4.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6839) [UI][Windows] MSI Installer Wizard modifications(Including logos text etc..)

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-6839:
---

Assignee: (was: Stephen Turner)

> [UI][Windows] MSI Installer Wizard modifications(Including logos text etc..)
> 
>
> Key: CLOUDSTACK-6839
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6839
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: Future, 4.5.0
>Reporter: Damodar Reddy T
> Fix For: 4.5.0
>
> Attachments: windows_installer.jpg
>
>
> The attached snapshot contains the steps involved in installation process of 
> cloudstack on management server. It has several steps and each step has it's 
> own wizard.
> We need to change the logo and the look and feel of each wizard based on ACS 
> standards.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6839) [UI][Windows] MSI Installer Wizard modifications(Including logos text etc..)

[Stephen Turner (JIRA)]

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

Stephen Turner updated CLOUDSTACK-6839:
---

Component/s: (was: UI)

> [UI][Windows] MSI Installer Wizard modifications(Including logos text etc..)
> 
>
> Key: CLOUDSTACK-6839
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6839
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: Future, 4.5.0
>Reporter: Damodar Reddy T
>Assignee: Stephen Turner
> Fix For: 4.5.0
>
> Attachments: windows_installer.jpg
>
>
> The attached snapshot contains the steps involved in installation process of 
> cloudstack on management server. It has several steps and each step has it's 
> own wizard.
> We need to change the logo and the look and feel of each wizard based on ACS 
> standards.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7352) [Automation] Test case test_01_list_vpncustomergateways_pagination trying to delete vpncustomergateways twice

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye resolved CLOUDSTACK-7352.


Resolution: Fixed

> [Automation] Test case test_01_list_vpncustomergateways_pagination trying to 
> delete vpncustomergateways twice 
> --
>
> Key: CLOUDSTACK-7352
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7352
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
> Fix For: 4.5.0
>
>
> Test case 
> integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways.test_01_list_vpncustomergateways_pagination
>  fails with below error 
> {noformat}
> xception: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  DEBUG: Response : FAILED
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  ERROR: marvinRequest : CmdName: 
>  object at 0x1971b790> Exception: ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", 
> line 374, in marvinRequest\nraise self.__lastError\n', "Exception: Job 
> failed: {jobprocstatus : 0, created : u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n"]
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 374, in marvinRequest
> raise self.__lastError
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  CRITICAL: EXCEPTION: test_01_list_vpncustomergateways_pagination: 
> ['Traceback (most recent call last):\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 345, in run\n
> self.tearDown()\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_escalations_vpncustomergateways.py",
>  line 94, in tearDown\ncleanup_resources(self.apiClient, 
> self.cleanup)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/lib/utils.py", line 121, in 
> cleanup_resources\nobj.delete(api_client)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/lib/base.py", line 3418, in 
> delete\napiclient.deleteVpnCustomerGateway(cmd)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 2333, in deleteVpnCustomerGateway\nresponse = 
> self.connection.marvinRequest(command, response_type=response, 
> method=method)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest\nraise e\n', "Exception: Job failed: {jobprocstatus 
> : 0, created : u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n"]
> - >> end

[jira] [Resolved] (CLOUDSTACK-7353) [Automation] Test case test_09_project_suspend, trying list VM under project after deleting this

[Girish Shilamkar (JIRA)]

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

Girish Shilamkar resolved CLOUDSTACK-7353.
--

Resolution: Fixed

> [Automation] Test case test_09_project_suspend,  trying list VM under project 
> after deleting this
> -
>
> Key: CLOUDSTACK-7353
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7353
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.5.0
>
>
> Run the test 
> integration.component.test_projects.TestProjectSuspendActivate.test_09_project_suspend
>  
> This test case fails with below error 
> {noformat}
> est_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> ===Jobid:0655909d-4dbc-4bab-aabb-ccd532ff7435 ; StartTime:Thu Aug 14 13:26:44 
> 2014 ; EndTime:Thu Aug 14 13:26:54 2014 ; TotalTime:-10===
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Response : {jobprocstatus : 0, created : u'2014-08-14T17:13:43-0700', 
> jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []}, 
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 1, jobid : 
> u'0655909d-4dbc-4bab-aabb-ccd532ff7435', jobresultcode : 0, jobinstanceid : 
> u'2def69e5-cb26-4506-8069-3237f049498b', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Destroying VM: 2def69e5-cb26-4506-8069-3237f049498b
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Payload: {'apiKey': 
> u'uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zoTzASxzSN0OSUnfoQ',
>  'projectid': u'463389ae-64fc-42b4-a555-a15dbbe455e4', 'response': 'json', 
> 'listall': True, 'command': 'listVirtualMachines', 'signature': 
> 'mzQe0vheGxDPynM+QkNzOJv12d8='}
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Sending GET Cmd : listVirtualMachines===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.49.195
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zoTzASxzSN0OSUnfoQ&projectid=463389ae-64fc-42b4-a555-a15dbbe455e4&command=listVirtualMachines&signature=mzQe0vheGxDPynM%2BQkNzOJv12d8%3D&response=json&listall=True
>  HTTP/1.1" 200 39
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Response : None
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): CRITICAL: 
> FAILED: test_09_project_suspend: ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run\n
> testMethod()\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_projects.py", line 
> 1625, in test_09_project_suspend\n"Check for a valid list accounts 
> response"\n', '  File "/usr/local/lib/python2.7/unittest/case.py", line 494, 
> in assertEqual\nassertion_func(first, second, msg=msg)\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n  
>   raise self.failureException(msg)\n', 'AssertionError: Check for a valid 
> list accounts response\n']
> - >> end captured logging << -
> Stacktrace
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_projects.py", line 
> 1625, in test_09_project_suspend
> "Check for a valid list accounts response"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> 'Check for a valid list accounts response\n >> begin 
> captured stdout << -\n=== TestName: 
> test_09_project_suspend | Status : FAILED ===\n\n\n- >> 
> end captured stdout << --\n >> begin 
> captured logging << 
> \ntest_08_cleanup_after_project_delete (int
> {noformat}
> Te

[jira] [Commented] (CLOUDSTACK-7352) [Automation] Test case test_01_list_vpncustomergateways_pagination trying to delete vpncustomergateways twice

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7352: Fixed issue in test_escalations_vpncustomergateways.py


> [Automation] Test case test_01_list_vpncustomergateways_pagination trying to 
> delete vpncustomergateways twice 
> --
>
> Key: CLOUDSTACK-7352
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7352
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
> Fix For: 4.5.0
>
>
> Test case 
> integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways.test_01_list_vpncustomergateways_pagination
>  fails with below error 
> {noformat}
> xception: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  DEBUG: Response : FAILED
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  ERROR: marvinRequest : CmdName: 
>  object at 0x1971b790> Exception: ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", 
> line 374, in marvinRequest\nraise self.__lastError\n', "Exception: Job 
> failed: {jobprocstatus : 0, created : u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n"]
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 374, in marvinRequest
> raise self.__lastError
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  CRITICAL: EXCEPTION: test_01_list_vpncustomergateways_pagination: 
> ['Traceback (most recent call last):\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 345, in run\n
> self.tearDown()\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_escalations_vpncustomergateways.py",
>  line 94, in tearDown\ncleanup_resources(self.apiClient, 
> self.cleanup)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/lib/utils.py", line 121, in 
> cleanup_resources\nobj.delete(api_client)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/lib/base.py", line 3418, in 
> delete\napiclient.deleteVpnCustomerGateway(cmd)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 2333, in deleteVpnCustomerGateway\nresponse = 
> self.connection.marvinRequest(command, response_type=response, 
> method=method)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest\nraise e\n', "Exception: Job failed: {jobprocstatus 
> : 0, created : u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-

[jira] [Commented] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

[ASF subversion and git services (JIRA)]

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

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

Commit 5a68f031ce3fe211dce2287d6ca67294e582b84f in cloudstack's branch 
refs/heads/hotfix/4.4-7193 from [~vbernat]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5a68f03 ]

CLOUDSTACK-7193: handle domain ID being an int

Recent versions of libvirt (at least 0.9.8) will return an int when
queried for the ID of a domain, not a string. This breaks some parts of
the `security_group.py` script which expects a string containing an
int. Notably, this breaks the part handling VM reboots which is
therefore not executed.

Signed-off-by: Vincent Bernat 
Signed-off-by: Sebastien Goasguen 


> Rebooting a VM doesn't update iptables rules
> 
>
> Key: CLOUDSTACK-7193
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.3.0
> Environment: Ubuntu Lucid 12.04 and more recent
>Reporter: Vincent Bernat
>
> Hi!
> Rebooting a VM doesn't update the iptables rules despite the change on the 
> interface name. To reproduce:
>  1. Starts two VM
>  2. Stop the first one.
>  3. Reboot the second one. It will use the vnet device of the first one.
>  4. Checks that the iptables rules for the second one are still referencing 
> the old interface.
> The defect seems to be in security_group.py. The periodic 
> "get_rule_logs_for_vm" which also handles rebooted VM fails because of the 
> following traceback:
> {code}
> 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
> Traceback (most recent call last):
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 705, in get_rule_logs_for_vms
> network_rules_for_rebooted_vm(name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 637, in network_rules_for_rebooted_vm
> [curr_domid, old_domid] = check_domid_changed(vm_name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 619, in check_domid_changed
> if (curr_domid is None) or (not curr_domid.isdigit()):
> AttributeError: 'int' object has no attribute 'isdigit'
> {code}
> This exception is catched by some try...except.
> On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
> I also checked that this is still the case with libvirt 1.2.4.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7346) iSCSI primary storage test should be skipped on VMWare

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7346: Skip iSCSI primary storage test for VMWare

Signed-off-by: Santhosh Edukulla 


> iSCSI primary storage test should be skipped on VMWare
> --
>
> Key: CLOUDSTACK-7346
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7346
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Assignee: John Dilley
>Priority: Critical
>
> As description - VMWare only supports VMFS which must be created in vCenter.
> We should create a smoke test for shared mount points (KVM), VMFS (VMWare) 
> and CIFS (Hyper-V) at some point, however given that no tests exist for the 
> other hypervisors yet, I'll postpone adding VMWare's primary storage test for 
> now.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

[ASF subversion and git services (JIRA)]

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

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

Commit e4ae5b20fb015bba6e77d82c2c585ff520d3efdf in cloudstack's branch 
refs/heads/4.3 from [~vbernat]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e4ae5b2 ]

CLOUDSTACK-7193: handle domain ID being an int

Recent versions of libvirt (at least 0.9.8) will return an int when
queried for the ID of a domain, not a string. This breaks some parts of
the `security_group.py` script which expects a string containing an
int. Notably, this breaks the part handling VM reboots which is
therefore not executed.

Signed-off-by: Vincent Bernat 
Signed-off-by: Sebastien Goasguen 


> Rebooting a VM doesn't update iptables rules
> 
>
> Key: CLOUDSTACK-7193
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.3.0
> Environment: Ubuntu Lucid 12.04 and more recent
>Reporter: Vincent Bernat
>
> Hi!
> Rebooting a VM doesn't update the iptables rules despite the change on the 
> interface name. To reproduce:
>  1. Starts two VM
>  2. Stop the first one.
>  3. Reboot the second one. It will use the vnet device of the first one.
>  4. Checks that the iptables rules for the second one are still referencing 
> the old interface.
> The defect seems to be in security_group.py. The periodic 
> "get_rule_logs_for_vm" which also handles rebooted VM fails because of the 
> following traceback:
> {code}
> 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
> Traceback (most recent call last):
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 705, in get_rule_logs_for_vms
> network_rules_for_rebooted_vm(name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 637, in network_rules_for_rebooted_vm
> [curr_domid, old_domid] = check_domid_changed(vm_name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 619, in check_domid_changed
> if (curr_domid is None) or (not curr_domid.isdigit()):
> AttributeError: 'int' object has no attribute 'isdigit'
> {code}
> This exception is catched by some try...except.
> On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
> I also checked that this is still the case with libvirt 1.2.4.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7193: handle domain ID being an int

Recent versions of libvirt (at least 0.9.8) will return an int when
queried for the ID of a domain, not a string. This breaks some parts of
the `security_group.py` script which expects a string containing an
int. Notably, this breaks the part handling VM reboots which is
therefore not executed.

Signed-off-by: Vincent Bernat 
Signed-off-by: Sebastien Goasguen 


> Rebooting a VM doesn't update iptables rules
> 
>
> Key: CLOUDSTACK-7193
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.3.0
> Environment: Ubuntu Lucid 12.04 and more recent
>Reporter: Vincent Bernat
>
> Hi!
> Rebooting a VM doesn't update the iptables rules despite the change on the 
> interface name. To reproduce:
>  1. Starts two VM
>  2. Stop the first one.
>  3. Reboot the second one. It will use the vnet device of the first one.
>  4. Checks that the iptables rules for the second one are still referencing 
> the old interface.
> The defect seems to be in security_group.py. The periodic 
> "get_rule_logs_for_vm" which also handles rebooted VM fails because of the 
> following traceback:
> {code}
> 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
> Traceback (most recent call last):
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 705, in get_rule_logs_for_vms
> network_rules_for_rebooted_vm(name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 637, in network_rules_for_rebooted_vm
> [curr_domid, old_domid] = check_domid_changed(vm_name)
>   File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", 
> line 619, in check_domid_changed
> if (curr_domid is None) or (not curr_domid.isdigit()):
> AttributeError: 'int' object has no attribute 'isdigit'
> {code}
> This exception is catched by some try...except.
> On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
> I also checked that this is still the case with libvirt 1.2.4.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7353) [Automation] Test case test_09_project_suspend, trying list VM under project after deleting this

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7353: Fixed issue with list VM in test_projects.py


> [Automation] Test case test_09_project_suspend,  trying list VM under project 
> after deleting this
> -
>
> Key: CLOUDSTACK-7353
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7353
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.5.0
>
>
> Run the test 
> integration.component.test_projects.TestProjectSuspendActivate.test_09_project_suspend
>  
> This test case fails with below error 
> {noformat}
> est_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> ===Jobid:0655909d-4dbc-4bab-aabb-ccd532ff7435 ; StartTime:Thu Aug 14 13:26:44 
> 2014 ; EndTime:Thu Aug 14 13:26:54 2014 ; TotalTime:-10===
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Response : {jobprocstatus : 0, created : u'2014-08-14T17:13:43-0700', 
> jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []}, 
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 1, jobid : 
> u'0655909d-4dbc-4bab-aabb-ccd532ff7435', jobresultcode : 0, jobinstanceid : 
> u'2def69e5-cb26-4506-8069-3237f049498b', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Destroying VM: 2def69e5-cb26-4506-8069-3237f049498b
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Payload: {'apiKey': 
> u'uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zoTzASxzSN0OSUnfoQ',
>  'projectid': u'463389ae-64fc-42b4-a555-a15dbbe455e4', 'response': 'json', 
> 'listall': True, 'command': 'listVirtualMachines', 'signature': 
> 'mzQe0vheGxDPynM+QkNzOJv12d8='}
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Sending GET Cmd : listVirtualMachines===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
> (1): 10.223.49.195
> requests.packages.urllib3.connectionpool: DEBUG: "GET 
> /client/api?apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zoTzASxzSN0OSUnfoQ&projectid=463389ae-64fc-42b4-a555-a15dbbe455e4&command=listVirtualMachines&signature=mzQe0vheGxDPynM%2BQkNzOJv12d8%3D&response=json&listall=True
>  HTTP/1.1" 200 39
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): DEBUG: 
> Response : None
> test_09_project_suspend 
> (integration.component.test_projects.TestProjectSuspendActivate): CRITICAL: 
> FAILED: test_09_project_suspend: ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run\n
> testMethod()\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_projects.py", line 
> 1625, in test_09_project_suspend\n"Check for a valid list accounts 
> response"\n', '  File "/usr/local/lib/python2.7/unittest/case.py", line 494, 
> in assertEqual\nassertion_func(first, second, msg=msg)\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n  
>   raise self.failureException(msg)\n', 'AssertionError: Check for a valid 
> list accounts response\n']
> - >> end captured logging << -
> Stacktrace
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_projects.py", line 
> 1625, in test_09_project_suspend
> "Check for a valid list accounts response"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> 'Check for a valid list accounts response\n >> begin 
> captured stdou

[jira] [Commented] (CLOUDSTACK-7006) Template ID is missing in ROOT volume usages

[ASF subversion and git services (JIRA)]

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

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

Commit 23b8196445d962f15f97df03e8dac9ae0b80e56b in cloudstack's branch 
refs/heads/hotfix/4.4-7006 from [~olemasle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=23b8196 ]

CLOUDSTACK-7006: Restore template ID in ROOT volume usages

Signed-off-by: Sebastien Goasguen 


> Template ID is missing in ROOT volume usages
> 
>
> Key: CLOUDSTACK-7006
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7006
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Minor
> Fix For: 4.3.1
>
>
> In previous versions of CloudStack, the template ID was recorded for ROOT 
> volume usages, when the VM is created from a template.
> Since CloudStack 4.2, the template ID isn't recorded anymore, due to a 
> regression in the EVENT_VOLUME_CREATE event publishing:
> In commit 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=730d04508507409065a432e2aac931225947f268,
>  the last EVENT_VOLUME_CREATE misses the template id, that was previously 
> set. It seems a simple copy-paste error.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7362) Resource tagging sometimes tags the wrong resource

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7362: fix wrong uuid issue for resource tags
(cherry picked from commit 838a1a8476cfb4308103b3797a281f843e208d38)


> Resource tagging sometimes tags the wrong resource
> --
>
> Key: CLOUDSTACK-7362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7362
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.4.1
>Reporter: Stephen Hoogendijk
>
> This problem occurs when the uuid of the resource you are about to tag begins 
> with a number that actually corresponds to the id field of an entry in the 
> same resource type table.
> Example:
> We want to tag security group with UUID 6cb95038-6b76-4905-bdf5-85bf0e0eda51 
> which has ID #5. But we also have a security group with ID #6 and UUID 
> d582e52c-f3c1-4e12-8e86-9dad0a5bd725. What happens is the following:
> First it runs this method:
> {code:java}
> long id = getResourceId(resourceId, resourceType);
> {code}
> which actually tries to find the entity by its UUID and returns the resource 
> id (numeric). This process goes off without a hitch.
> Next, it actually tries to find the UUID of the resource (because you can 
> also send in the internal (numeric) identifier):
> {code:java}
> String resourceUuid = getUuid(resourceId, resourceType)
> {code}
> Now this is when the magic starts happening, this is what's happening inside 
> the method:
> {code:java}
> entity = _entityMgr.findById(clazz, resourceId);
> if (entity != null && entity instanceof Identity) {
> return ((Identity)entity).getUuid();
>}
> {code}
> Because our resourceId starts with a numeric 6 the findById method somehow 
> returns the object that actually has the internal numeric identifier 6. Thus 
> it ends up tagging the wrong object.
> This issue can be resolved by changing the getUUID() method to:
> {code:java}
> @Override
> public String getUuid(String resourceId, ResourceObjectType resourceType) 
> {
> Class clazz = s_typeMap.get(resourceType);
> Object entity = _entityMgr.findByUuid(clazz, resourceId);
> if (entity != null) {
> return ((Identity)entity).getUuid();
> }
> entity = _entityMgr.findById(clazz, resourceId);
> if (entity != null && entity instanceof Identity) {
> return ((Identity)entity).getUuid();
> }
> return resourceId;
> }
> {code}
> What i would like to know is if this is a known issue or not? I couldn't find 
> a bug report here in Jira. If this is an unknown bug then i will go ahead and 
> submit the patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7362) Resource tagging sometimes tags the wrong resource

[Wei Zhou (JIRA)]

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

Wei Zhou resolved CLOUDSTACK-7362.
--

Resolution: Fixed
  Assignee: Wei Zhou

> Resource tagging sometimes tags the wrong resource
> --
>
> Key: CLOUDSTACK-7362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7362
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.4.1
>Reporter: Stephen Hoogendijk
>Assignee: Wei Zhou
>
> This problem occurs when the uuid of the resource you are about to tag begins 
> with a number that actually corresponds to the id field of an entry in the 
> same resource type table.
> Example:
> We want to tag security group with UUID 6cb95038-6b76-4905-bdf5-85bf0e0eda51 
> which has ID #5. But we also have a security group with ID #6 and UUID 
> d582e52c-f3c1-4e12-8e86-9dad0a5bd725. What happens is the following:
> First it runs this method:
> {code:java}
> long id = getResourceId(resourceId, resourceType);
> {code}
> which actually tries to find the entity by its UUID and returns the resource 
> id (numeric). This process goes off without a hitch.
> Next, it actually tries to find the UUID of the resource (because you can 
> also send in the internal (numeric) identifier):
> {code:java}
> String resourceUuid = getUuid(resourceId, resourceType)
> {code}
> Now this is when the magic starts happening, this is what's happening inside 
> the method:
> {code:java}
> entity = _entityMgr.findById(clazz, resourceId);
> if (entity != null && entity instanceof Identity) {
> return ((Identity)entity).getUuid();
>}
> {code}
> Because our resourceId starts with a numeric 6 the findById method somehow 
> returns the object that actually has the internal numeric identifier 6. Thus 
> it ends up tagging the wrong object.
> This issue can be resolved by changing the getUUID() method to:
> {code:java}
> @Override
> public String getUuid(String resourceId, ResourceObjectType resourceType) 
> {
> Class clazz = s_typeMap.get(resourceType);
> Object entity = _entityMgr.findByUuid(clazz, resourceId);
> if (entity != null) {
> return ((Identity)entity).getUuid();
> }
> entity = _entityMgr.findById(clazz, resourceId);
> if (entity != null && entity instanceof Identity) {
> return ((Identity)entity).getUuid();
> }
> return resourceId;
> }
> {code}
> What i would like to know is if this is a known issue or not? I couldn't find 
> a bug report here in Jira. If this is an unknown bug then i will go ahead and 
> submit the patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7308) Tags not available for security group rules

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7308: add tags to all security group rules
(cherry picked from commit ae1b87ca23997bcba75bfc7f59e83026e31a68fc)


> Tags not available for security group rules
> ---
>
> Key: CLOUDSTACK-7308
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7308
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Stephen Hoogendijk
>Priority: Minor
>  Labels: security-groups, tagging
>
> Hi all,
> Our customers asked for the ability to name their firewall/security group 
> rules (such as web 80/ftp 21 etc). To accomplish this we should add tagging 
> support for Security Group Rules.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7006) Template ID is missing in ROOT volume usages

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7006: Restore template ID in ROOT volume usages

Signed-off-by: Sebastien Goasguen 


> Template ID is missing in ROOT volume usages
> 
>
> Key: CLOUDSTACK-7006
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7006
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Minor
> Fix For: 4.3.1
>
>
> In previous versions of CloudStack, the template ID was recorded for ROOT 
> volume usages, when the VM is created from a template.
> Since CloudStack 4.2, the template ID isn't recorded anymore, due to a 
> regression in the EVENT_VOLUME_CREATE event publishing:
> In commit 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=730d04508507409065a432e2aac931225947f268,
>  the last EVENT_VOLUME_CREATE misses the template id, that was previously 
> set. It seems a simple copy-paste error.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7362) Resource tagging sometimes tags the wrong resource

[ASF subversion and git services (JIRA)]

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

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

Commit 838a1a8476cfb4308103b3797a281f843e208d38 in cloudstack's branch 
refs/heads/4.4 from [~weizhou]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=838a1a8 ]

CLOUDSTACK-7362: fix wrong uuid issue for resource tags


> Resource tagging sometimes tags the wrong resource
> --
>
> Key: CLOUDSTACK-7362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7362
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.4.1
>Reporter: Stephen Hoogendijk
>
> This problem occurs when the uuid of the resource you are about to tag begins 
> with a number that actually corresponds to the id field of an entry in the 
> same resource type table.
> Example:
> We want to tag security group with UUID 6cb95038-6b76-4905-bdf5-85bf0e0eda51 
> which has ID #5. But we also have a security group with ID #6 and UUID 
> d582e52c-f3c1-4e12-8e86-9dad0a5bd725. What happens is the following:
> First it runs this method:
> {code:java}
> long id = getResourceId(resourceId, resourceType);
> {code}
> which actually tries to find the entity by its UUID and returns the resource 
> id (numeric). This process goes off without a hitch.
> Next, it actually tries to find the UUID of the resource (because you can 
> also send in the internal (numeric) identifier):
> {code:java}
> String resourceUuid = getUuid(resourceId, resourceType)
> {code}
> Now this is when the magic starts happening, this is what's happening inside 
> the method:
> {code:java}
> entity = _entityMgr.findById(clazz, resourceId);
> if (entity != null && entity instanceof Identity) {
> return ((Identity)entity).getUuid();
>}
> {code}
> Because our resourceId starts with a numeric 6 the findById method somehow 
> returns the object that actually has the internal numeric identifier 6. Thus 
> it ends up tagging the wrong object.
> This issue can be resolved by changing the getUUID() method to:
> {code:java}
> @Override
> public String getUuid(String resourceId, ResourceObjectType resourceType) 
> {
> Class clazz = s_typeMap.get(resourceType);
> Object entity = _entityMgr.findByUuid(clazz, resourceId);
> if (entity != null) {
> return ((Identity)entity).getUuid();
> }
> entity = _entityMgr.findById(clazz, resourceId);
> if (entity != null && entity instanceof Identity) {
> return ((Identity)entity).getUuid();
> }
> return resourceId;
> }
> {code}
> What i would like to know is if this is a known issue or not? I couldn't find 
> a bug report here in Jira. If this is an unknown bug then i will go ahead and 
> submit the patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7308) Tags not available for security group rules

[ASF subversion and git services (JIRA)]

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

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

Commit ae1b87ca23997bcba75bfc7f59e83026e31a68fc in cloudstack's branch 
refs/heads/4.4 from [~weizhou]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ae1b87c ]

CLOUDSTACK-7308: add tags to all security group rules


> Tags not available for security group rules
> ---
>
> Key: CLOUDSTACK-7308
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7308
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Stephen Hoogendijk
>Priority: Minor
>  Labels: security-groups, tagging
>
> Hi all,
> Our customers asked for the ability to name their firewall/security group 
> rules (such as web 80/ftp 21 etc). To accomplish this we should add tagging 
> support for Security Group Rules.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7218) [Automation] NPE observed while deleting account in automation run

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7218:
---

Hi Animesh,

Started working on it, making code changes. After this i will run BVT.

Thanks,
Jayapal

> [Automation] NPE observed while deleting account in automation run
> --
>
> Key: CLOUDSTACK-7218
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7218
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue is observed in automation log, NPE thrown while deleting account
> 2014-07-31 02:20:56,102 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) There are no static 
> nat
>  rules to apply for ip id=28
> 2014-07-31 02:20:56,105 WARN  [c.c.u.AccountManagerImpl] 
> (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) Failed to cleanup 
> accou
> nt 
> Acct[b1cf2381-ab36-4ebc-90ff-f08acaf5e02d-test-account-TestVmNetworkOperations-test_add_static_nat_rule_1_ISOLATED-YI0OCS]
>  due to
> java.lang.NullPointerException
> at 
> com.cloud.network.rules.RulesManagerImpl.createStaticNatForIp(RulesManagerImpl.java:1391)
> at 
> com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1321)
> at 
> com.cloud.network.rules.RulesManagerImpl.revokeAllPFAndStaticNatRulesForIp(RulesManagerImpl.java:1104)
> at sun.reflect.GeneratedMethodAccessor524.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy105.revokeAllPFAndStaticNatRulesForIp(Unknown 
> Source)
> at 
> com.cloud.network.IpAddressManagerImpl.cleanupIpResources(IpAddressManagerImpl.java:540)
> at 
> com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:936)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.cleanupNetworkResources(NetworkOrchestrator.java:2650)
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2196)
> at 
> com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:793)
> at 
> com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:667)
> at 
> com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1441)
> at sun.reflect.GeneratedMethodAccessor542.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflectiv

[jira] [Created] (CLOUDSTACK-7363) [Automation] test_vmware_drs should skip on non-VMWare Hypervisors

[Alex Brett (JIRA)]

Alex Brett created CLOUDSTACK-7363:
--

 Summary: [Automation] test_vmware_drs should skip on non-VMWare 
Hypervisors
 Key: CLOUDSTACK-7363
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7363
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Reporter: Alex Brett
Assignee: Alex Brett
 Fix For: 4.5.0


test/integration/component/test_vmware_drs.py is testing pure VMWare features, 
so is only valid if run on VMWare hosts, however it currently doesn't check 
this.

It should test the hypervisor type and skip if a non-VMWare hypervisor is in 
use.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

[Likitha Shetty (JIRA)]

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

Likitha Shetty updated CLOUDSTACK-7351:
---

Assignee: Harikrishna Patnala  (was: Likitha Shetty)

> [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
> 
>
> Key: CLOUDSTACK-7351
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Harikrishna Patnala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CLOUDSTACK-7351.rar
>
>
> This issue observed while running the test case 
> integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
> This test case deploying VM with below command 
> 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
> account=test-TestVMAcc
> ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze
> Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
> TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543
> e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
> This deployment failed with below error 
> 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
> Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
> 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
> (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
> parameter is needed to deploy VM or the hypervisor parameter value passed is 
> invalid
> Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6169) assignVirtualMachine leaves associated tags assigned to old account

[Namita Chaudhari (JIRA)]

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

Namita Chaudhari reassigned CLOUDSTACK-6169:


Assignee: Namita Chaudhari  (was: Prachi Damle)

> assignVirtualMachine leaves associated tags assigned to old account
> ---
>
> Key: CLOUDSTACK-6169
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6169
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0, 4.3.0, 4.4.0
>Reporter: Marcus Sorensen
>Assignee: Namita Chaudhari
> Fix For: 4.4.0
>
>
> I'm not 100% sure this is a bug, but it seems so. If you move a virtual 
> machine between accounts via 'assignVirtualMachine', then list the virtual 
> machine, any associated resource tags show the old account/domainid. This is 
> confusing, but could also be a bad information leak



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7352) [Automation] Test case test_01_list_vpncustomergateways_pagination trying to delete vpncustomergateways twice

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye updated CLOUDSTACK-7352:
---

Status: Reviewable  (was: In Progress)

> [Automation] Test case test_01_list_vpncustomergateways_pagination trying to 
> delete vpncustomergateways twice 
> --
>
> Key: CLOUDSTACK-7352
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7352
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
> Fix For: 4.5.0
>
>
> Test case 
> integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways.test_01_list_vpncustomergateways_pagination
>  fails with below error 
> {noformat}
> xception: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  DEBUG: Response : FAILED
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  ERROR: marvinRequest : CmdName: 
>  object at 0x1971b790> Exception: ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", 
> line 374, in marvinRequest\nraise self.__lastError\n', "Exception: Job 
> failed: {jobprocstatus : 0, created : u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n"]
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 374, in marvinRequest
> raise self.__lastError
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
> test_01_list_vpncustomergateways_pagination 
> (integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
>  CRITICAL: EXCEPTION: test_01_list_vpncustomergateways_pagination: 
> ['Traceback (most recent call last):\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 345, in run\n
> self.tearDown()\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_escalations_vpncustomergateways.py",
>  line 94, in tearDown\ncleanup_resources(self.apiClient, 
> self.cleanup)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/lib/utils.py", line 121, in 
> cleanup_resources\nobj.delete(api_client)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/lib/base.py", line 3418, in 
> delete\napiclient.deleteVpnCustomerGateway(cmd)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 2333, in deleteVpnCustomerGateway\nresponse = 
> self.connection.marvinRequest(command, response_type=response, 
> method=method)\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest\nraise e\n', "Exception: Job failed: {jobprocstatus 
> : 0, created : u'2014-08-14T16:40:08-0700', cmd : 
> u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd', 
> userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
> u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer 
> gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n"]
> -

[jira] [Comment Edited] (CLOUDSTACK-6169) assignVirtualMachine leaves associated tags assigned to old account

[Namita Chaudhari (JIRA)]

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

Namita Chaudhari edited comment on CLOUDSTACK-6169 at 8/18/14 9:58 AM:
---

I have uploaded the review patch at https://reviews.apache.org/r/24794/


was (Author: namita.chaudh...@sungard.com):
I have uploaded the review patch a https://reviews.apache.org/r/24794/

> assignVirtualMachine leaves associated tags assigned to old account
> ---
>
> Key: CLOUDSTACK-6169
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6169
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0, 4.3.0, 4.4.0
>Reporter: Marcus Sorensen
>Assignee: Namita Chaudhari
> Fix For: 4.4.0
>
>
> I'm not 100% sure this is a bug, but it seems so. If you move a virtual 
> machine between accounts via 'assignVirtualMachine', then list the virtual 
> machine, any associated resource tags show the old account/domainid. This is 
> confusing, but could also be a bad information leak



--
This message was sent by Atlassian JIRA
(v6.2#6252)