Re: Review Request 28611: CLOUDSTACK-8007: Fixed the script 'test_vm_passwdenabled.py' - Template created by Admin should have public access to be used for regular User VM Deployment
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28611/#review63866 --- Ship it! Ship It! - sangeetha hariharan On Dec. 2, 2014, 10:40 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28611/ --- (Updated Dec. 2, 2014, 10:40 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-8007 https://issues.apache.org/jira/browse/CLOUDSTACK-8007 Repository: cloudstack-git Description --- Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. Since the Admin created the template from the Volume, the Admin is the owner of the private template. In order to deploy a VM for the Regular Account the template created by Admin should have public Access. Diffs - test/integration/component/test_vm_passwdenabled.py 1b556da Diff: https://reviews.apache.org/r/28611/diff/ Testing --- Test get VM password for password enabled template ... === TestName: test_11_get_vm_password | Status : SUCCESS === ok -- Ran 1 test in 706.715s OK Thanks, Chandan Purushothama
Re: Review Request 28579: CLOUDSTACK-7996: Fixed the script test_tags.py - Tags and Template should belong to the User Account to test the case
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28579/#review63580 --- Ship it! Ship It! - sangeetha hariharan On Dec. 1, 2014, 10:35 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28579/ --- (Updated Dec. 1, 2014, 10:35 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7996 https://issues.apache.org/jira/browse/CLOUDSTACK-7996 Repository: cloudstack-git Description --- Currently the tags and template belong to the Admin Account and not the User Account. Listing tags is being done as the regular User Account. This results in test case failure as no tags are returned to the regular User. Hence the inconsistency in creation of template, tags and listing them needs to be corrected for the test case to work. Diffs - test/integration/component/test_tags.py c5a8ced Diff: https://reviews.apache.org/r/28579/diff/ Testing --- Test creation, listing and deletion tag on templates ... === TestName: test_06_template_tag | Status : SUCCESS === ok -- Ran 1 test in 441.116s OK Thanks, Chandan Purushothama
Re: Review Request 28489: CLOUDSTACK-7978 : Fixed the script 'test_egress_rules.py' - Zone Network Type Information should to be passed to VirtualMachine create method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28489/#review63164 --- Ship it! Ship It! - sangeetha hariharan On Nov. 27, 2014, 12:09 a.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28489/ --- (Updated Nov. 27, 2014, 12:09 a.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7978 https://issues.apache.org/jira/browse/CLOUDSTACK-7978 Repository: cloudstack-git Description --- Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. Diffs - test/integration/component/test_egress_rules.py 0f05c07 Diff: https://reviews.apache.org/r/28489/diff/ Testing --- Executed One Test to prove the fix: Test authorize ingress rule ... === TestName: test_authorizeIngressRule | Status : SUCCESS === ok -- Ran 1 test in 126.613s OK Thanks, Chandan Purushothama
Re: Review Request 28490: CLOUDSTACK-7979 : Fixed the script 'test_security_groups.py' - Zone Network Type Information should to be passed to VirtualMachine create method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28490/#review63165 --- Ship it! Ship It! - sangeetha hariharan On Nov. 27, 2014, 12:14 a.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28490/ --- (Updated Nov. 27, 2014, 12:14 a.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7979 https://issues.apache.org/jira/browse/CLOUDSTACK-7979 Repository: cloudstack-git Description --- Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. Diffs - test/integration/component/test_security_groups.py 89317f4 Diff: https://reviews.apache.org/r/28490/diff/ Testing --- Executed One Test to prove the fix. This test belongs to a different test suite. But the fix is the same: Test authorize ingress rule ... === TestName: test_authorizeIngressRule | Status : SUCCESS === ok Ran 1 test in 126.613s OK Thanks, Chandan Purushothama
Re: Review Request 28492: CLOUDSTACK-7980 : Fixed the script '/maint/test_egress_rules_host_maintenance.py' - Zone Network Type Information should to be passed to VirtualMachine create method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28492/#review63166 --- Ship it! Ship It! - sangeetha hariharan On Nov. 27, 2014, 12:19 a.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28492/ --- (Updated Nov. 27, 2014, 12:19 a.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7980 https://issues.apache.org/jira/browse/CLOUDSTACK-7980 Repository: cloudstack-git Description --- Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. Diffs - test/integration/component/maint/test_egress_rules_host_maintenance.py a27ada3 Diff: https://reviews.apache.org/r/28492/diff/ Testing --- Executed One Test to prove the fix. This test belongs to a different test suite. But the fix is the same: Test authorize ingress rule ... === TestName: test_authorizeIngressRule | Status : SUCCESS === ok Ran 1 test in 126.613s OK Thanks, Chandan Purushothama
Re: Review Request 28292: CLOUDSTACK-7955 : Fixed the script 'test_project_limits.py' - Register Template in the Project to test the Template limits on the project
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28292/#review62647 --- Ship it! Ship It! - sangeetha hariharan On Nov. 20, 2014, 7:26 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28292/ --- (Updated Nov. 20, 2014, 7:26 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7955 https://issues.apache.org/jira/browse/CLOUDSTACK-7955 Repository: cloudstack-git Description --- Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. This requires the test case test_07_templates_per_project to be changed. The test case should test the limits by registering the template in the project instead of creating templates from Volumes. Diffs - test/integration/component/test_project_limits.py 5d37f0b Diff: https://reviews.apache.org/r/28292/diff/ Testing --- Test Limit number of guest account specific networks ... === TestName: test_maxAccountNetworks | Status : SUCCESS === ok Test project limits for domain admin ... === TestName: test_01_project_limits | Status : SUCCESS === ok Test project limits for normal user ... === TestName: test_02_project_limits_normal_user | Status : SUCCESS === ok Test VM limit per project ... === TestName: test_03_vm_per_project | Status : SUCCESS === ok Test Public IP limit per project ... === TestName: test_04_publicip_per_project | Status : SUCCESS === ok Test Snapshot limit per project ... === TestName: test_05_snapshots_per_project | Status : SUCCESS === ok Test Volumes limit per project ... === TestName: test_06_volumes_per_project | Status : SUCCESS === ok Test Templates limit per project ... === TestName: test_07_templates_per_project | Status : SUCCESS === ok -- Ran 8 tests in 1103.761s OK Thanks, Chandan Purushothama
Re: Review Request 28300: CLOUDSTACK-7956 : Fixed the script 'test_project_usage.py' - Register Template in the Project to test the Template limits on the project
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28300/#review62649 --- Ship it! Ship It! - sangeetha hariharan On Nov. 20, 2014, 9:49 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28300/ --- (Updated Nov. 20, 2014, 9:49 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7956 https://issues.apache.org/jira/browse/CLOUDSTACK-7956 Repository: cloudstack-git Description --- Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. This requires the test case test_01_template_usage to be changed. The test case should test the limits by registering the template in the project instead of creating templates from Volumes. Diffs - test/integration/component/test_project_usage.py 2627504 Diff: https://reviews.apache.org/r/28300/diff/ Testing --- Test Upload/ delete a template and verify correct usage is generated ... === TestName: test_01_template_usage | Status : SUCCESS === ok -- Ran 1 test in 312.740s OK Thanks, Chandan Purushothama
Re: Review Request 28179: CLOUDSTACK-7928 : Fixed the script 'test_vpc_vm_life_cycle.py' - Removed the Invalid test cases for Stopped VPC VR Scenario
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28179/#review62071 --- Ship it! Ship It! - sangeetha hariharan On Nov. 18, 2014, 5:47 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28179/ --- (Updated Nov. 18, 2014, 5:47 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7928 https://issues.apache.org/jira/browse/CLOUDSTACK-7928 Repository: cloudstack-git Description --- Following Test Cases currently fail in TestVMLifeCycleStoppedVPCVR Test Suite: test_07_migrate_instance_in_network test_08_user_data test_09_meta_data test_10_expunge_instance_in_network The test cases fail for the obvious reason since the VPC VR is stopped. The Stopped VPCVR doesnt allow the traffic to or from the Guest VMs. Hence the test cases are not valid to be tested in such a scenario and should be removed. Removed the test cases that are failing due to invalid scenario Diffs - test/integration/component/test_vpc_vm_life_cycle.py 7a1fd8a Diff: https://reviews.apache.org/r/28179/diff/ Testing --- Testing not done Thanks, Chandan Purushothama
Re: Review Request 27305: CLOUDSTACK-7810 : Fixed the script test_vpc_vm_life_cycle.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27305/#review61829 --- Ship it! Ship It! - sangeetha hariharan On Nov. 15, 2014, 11:04 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27305/ --- (Updated Nov. 15, 2014, 11:04 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7810 https://issues.apache.org/jira/browse/CLOUDSTACK-7810 Repository: cloudstack-git Description --- Test Cases are trying to validate SSH access and failing. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_vpc_vm_life_cycle.py 84e27df Diff: https://reviews.apache.org/r/27305/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27845: CLOUDSTACK-7876 - Fixed the script 'test_vpc_vm_life_cycle.py' - Prevent Destruction of VM before it can be recovered
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27845/#review60818 --- Ship it! Ship It! - sangeetha hariharan On Nov. 10, 2014, 11:47 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27845/ --- (Updated Nov. 10, 2014, 11:47 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7876 https://issues.apache.org/jira/browse/CLOUDSTACK-7876 Repository: cloudstack-git Description --- Multiple Test Cases in the Test Suite Fail as the VMs destroy_instance_in_network test case step ends up expunged before the can be recovered for the subsequent test cases. Hence it is important not to wait for too much time before the VMs can be recovered. As a fix, I reshuffled the code such that two VM destroy operations are not performed one after another immediately. This will cut down the time for the VMs retreival. Diffs - test/integration/component/test_vpc_vm_life_cycle.py e8df680 Diff: https://reviews.apache.org/r/27845/diff/ Testing --- Test deploy virtual machine in two isolated networks ... === TestName: test_01_deploy_vm_two_isolated_nw | Status : SUCCESS === ok Test deploy virtual machine when VPC VR in stopped state ... === TestName: test_02_deploy_vm_vpcvr_stopped | Status : SUCCESS === ok Test deploy an instance in VPC networks ... === TestName: test_01_deploy_instance_in_network | Status : SUCCESS === ok Test stop an instance in VPC networks ... === TestName: test_02_stop_instance_in_network | Status : SUCCESS === ok Test start an instance in VPC networks ... === TestName: test_03_start_instance_in_network | Status : SUCCESS === ok Test reboot an instance in VPC networks ... === TestName: test_04_reboot_instance_in_network | Status : SUCCESS === ok Test destroy an instance in VPC networks ... === TestName: test_05_destroy_instance_in_network | Status : SUCCESS === ok Test migrate an instance in VPC networks ... SKIP: Could not find suitable host for migration, please ensure setup has required no. of hosts Test user data in virtual machines ... === TestName: test_07_user_data | Status : SUCCESS === ok Test meta data in virtual machines ... === TestName: test_08_meta_data | Status : SUCCESS === ok Test expunge an instance in VPC networks ... === TestName: test_09_expunge_instance_in_network | Status : FAILED === FAIL [Please note that this failure happened due to intermmitent network issue which is Independent of the fix] Test deploy an instance in VPC networks ... === TestName: test_01_deploy_instance_in_network | Status : SUCCESS === ok Test stop an instance in VPC networks ... === TestName: test_02_stop_instance_in_network | Status : SUCCESS === ok Test start an instance in VPC networks ... === TestName: test_03_start_instance_in_network | Status : SUCCESS === ok Test reboot an instance in VPC networks ... === TestName: test_04_reboot_instance_in_network | Status : SUCCESS === ok Test destroy an instance in VPC networks ... === TestName: test_05_destroy_instance_in_network | Status : SUCCESS === ok Test recover an instance in VPC networks ... === TestName: test_06_recover_instance_in_network | Status : SUCCESS === ok Test migrate an instance in VPC networks ... === TestName: test_07_migrate_instance_in_network | Status : SUCCESS === ok Test user data in virtual machines ... === TestName: test_08_user_data | Status : SUCCESS === ok Test meta data in virtual machines ... === TestName: test_09_meta_data | Status : SUCCESS === ok Test expunge an instance in VPC networks ... === TestName: test_10_expunge_instance_in_network | Status : SUCCESS === ok === TestName: test_10_expunge_instance_in_network | Status : EXCEPTION === [Please note that this failure happened due to intermmitent network issue which is Independent of the fix] ERROR Test deploy an instance in VPC networks ... === TestName: test_01_deploy_instance_in_network | Status : SUCCESS === ok Test stop an instance in VPC networks ... === TestName: test_02_stop_instance_in_network | Status : SUCCESS === ok Test start an instance in VPC networks ... === TestName: test_03_start_instance_in_network | Status : SUCCESS === ok Test reboot an instance in VPC networks ... === TestName: test_04_reboot_instance_in_network | Status : SUCCESS === ok Test destroy an instance in VPC networks ... === TestName: test_05_destroy_instance_in_network | Status : SUCCESS === ok Test migrate an instance in VPC networks ... === TestName: test_07_migrate_instance_in_network | Status : SUCCESS === ok Test user data
Re: Review Request 27307: CLOUDSTACK-7811 : Fixed the script test_persistent_networks.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27307/#review58929 --- Ship it! Ship It! - sangeetha hariharan On Oct. 28, 2014, 8:50 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27307/ --- (Updated Oct. 28, 2014, 8:50 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7811 https://issues.apache.org/jira/browse/CLOUDSTACK-7811 Repository: cloudstack-git Description --- Test Cases are trying to validate SSH access and failing. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_persistent_networks.py 65b109f Diff: https://reviews.apache.org/r/27307/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27308: CLOUDSTACK-7812 : Fixed the script maint/test_redundant_router_network_rules.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27308/#review58931 --- Ship it! Ship It! - sangeetha hariharan On Oct. 28, 2014, 8:55 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27308/ --- (Updated Oct. 28, 2014, 8:55 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7812 https://issues.apache.org/jira/browse/CLOUDSTACK-7812 Repository: cloudstack-git Description --- Test Cases are trying to validate SSH access and failing. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/maint/test_redundant_router_network_rules.py 12c4d2c Diff: https://reviews.apache.org/r/27308/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27195: CLOUDSTACK-7788: Fixed the script test_escalations_instances.py - Regular Users should not use expunge parameter for destroying a VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27195/#review58510 --- Can we have the sleep interval calculated from the expunge global config parameters? - sangeetha hariharan On Oct. 25, 2014, 2:59 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27195/ --- (Updated Oct. 25, 2014, 2:59 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7788 https://issues.apache.org/jira/browse/CLOUDSTACK-7788 Repository: cloudstack-git Description --- Regular Users do not have permissions to expunge a VM with expunge parameter. It is only available for admin to use. Correct the test script accordingly Diffs - test/integration/component/test_escalations_instances.py 1aaa688 Diff: https://reviews.apache.org/r/27195/diff/ Testing --- @Desc: Test List Instances pagination ... === TestName: test_01_list_instances_pagination | Status : SUCCESS === ok @Desc: Test List Running VM's ... === TestName: test_02_list_Running_vm | Status : SUCCESS === ok @Desc: Test List Stopped VM's ... === TestName: test_03_list_Stopped_vm | Status : SUCCESS === ok @Desc: Test List Destroyed VM's ... === TestName: test_04_list_Destroyed_vm | Status : SUCCESS === ok @Desc: Test List VM by Id ... === TestName: test_05_list_vm_by_id | Status : SUCCESS === ok @Desc: Test List VM's by Name ... === TestName: test_06_list_vm_by_name | Status : SUCCESS === ok @Desc: Test List VM's by Name and State ... === TestName: test_07_list_vm_by_name_state | Status : SUCCESS === ok @Desc: Test List VM by Zone. ... === TestName: test_08_list_vm_by_zone | Status : SUCCESS === ok @Desc: Test List VM by Zone. ... === TestName: test_09_list_vm_by_zone_name | Status : SUCCESS === ok @Desc: Test List VM by Zone. ... === TestName: test_10_list_vm_by_zone_name_state | Status : SUCCESS === ok Thanks, Chandan Purushothama
Re: Review Request 27193: CLOUDSTACK-7788: Fixed the script 'test_dynamic_compute_offering.py' to be run only on hardware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27193/#review58512 --- Ship it! Ship It! - sangeetha hariharan On Oct. 25, 2014, 2:38 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27193/ --- (Updated Oct. 25, 2014, 2:38 p.m.) Review request for cloudstack, sangeetha hariharan and Santhosh Edukulla. Bugs: CLOUDSTACK-7788 https://issues.apache.org/jira/browse/CLOUDSTACK-7788 Repository: cloudstack-git Description --- Test Cases are trying to perform operations that can only be done on hardware and supported hypervisors. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_dynamic_compute_offering.py a3e2d56 Diff: https://reviews.apache.org/r/27193/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27193: CLOUDSTACK-7788: Fixed the script 'test_dynamic_compute_offering.py' to be run only on hardware
On Oct. 25, 2014, 4:16 p.m., sangeetha hariharan wrote: Ship It! In this case, simulator does not support for scale operation which is the reason for the failures. Please log a ticket to have simulator support for this operation. - sangeetha --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27193/#review58512 --- On Oct. 25, 2014, 2:38 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27193/ --- (Updated Oct. 25, 2014, 2:38 p.m.) Review request for cloudstack, sangeetha hariharan and Santhosh Edukulla. Bugs: CLOUDSTACK-7788 https://issues.apache.org/jira/browse/CLOUDSTACK-7788 Repository: cloudstack-git Description --- Test Cases are trying to perform operations that can only be done on hardware and supported hypervisors. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_dynamic_compute_offering.py a3e2d56 Diff: https://reviews.apache.org/r/27193/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27192: CLOUDSTACK-7787: Fixed the script 'test_lb_secondary_ip.py' to be run only on hardware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27192/#review58515 --- Ship it! This patch looks good. All test cases requiring to ssh to VMs for validation has been marked for not being picked up by simulator runs. - sangeetha hariharan On Oct. 25, 2014, 2:23 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27192/ --- (Updated Oct. 25, 2014, 2:23 p.m.) Review request for cloudstack, sangeetha hariharan and Santhosh Edukulla. Bugs: CLOUDSTACK-7787 https://issues.apache.org/jira/browse/CLOUDSTACK-7787 Repository: cloudstack-git Description --- Test Cases are trying to validate SSH access and failing. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_lb_secondary_ip.py 23ff1ee Diff: https://reviews.apache.org/r/27192/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27191: CLOUDSTACK-7786 : Fixed the script 'test_haproxy.py' to be run only on hardware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27191/#review58516 --- Ship it! Ship It! - sangeetha hariharan On Oct. 25, 2014, 2:12 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27191/ --- (Updated Oct. 25, 2014, 2:12 p.m.) Review request for cloudstack, sangeetha hariharan and Santhosh Edukulla. Bugs: CLOUDSTACK-7786 https://issues.apache.org/jira/browse/CLOUDSTACK-7786 Repository: cloudstack-git Description --- Test Cases are trying to validate SSH access and failing. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_haproxy.py 2778902 Diff: https://reviews.apache.org/r/27191/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27191: CLOUDSTACK-7786 : Fixed the script 'test_haproxy.py' to be run only on hardware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27191/#review58517 --- Ship it! Ship It! - sangeetha hariharan On Oct. 25, 2014, 2:12 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27191/ --- (Updated Oct. 25, 2014, 2:12 p.m.) Review request for cloudstack, sangeetha hariharan and Santhosh Edukulla. Bugs: CLOUDSTACK-7786 https://issues.apache.org/jira/browse/CLOUDSTACK-7786 Repository: cloudstack-git Description --- Test Cases are trying to validate SSH access and failing. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator Diffs - test/integration/component/test_haproxy.py 2778902 Diff: https://reviews.apache.org/r/27191/diff/ Testing --- Changed the tags on Tests. Testing not done Thanks, Chandan Purushothama
Re: Review Request 27195: CLOUDSTACK-7788: Fixed the script test_escalations_instances.py - Regular Users should not use expunge parameter for destroying a VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27195/#review58525 --- Ship it! Ship It! - sangeetha hariharan On Oct. 25, 2014, 6:50 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27195/ --- (Updated Oct. 25, 2014, 6:50 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7788 https://issues.apache.org/jira/browse/CLOUDSTACK-7788 Repository: cloudstack-git Description --- Regular Users do not have permissions to expunge a VM with expunge parameter. It is only available for admin to use. Correct the test script accordingly Diffs - test/integration/component/test_escalations_instances.py 1aaa688 Diff: https://reviews.apache.org/r/27195/diff/ Testing --- @Desc: Test List Instances pagination ... === TestName: test_01_list_instances_pagination | Status : SUCCESS === ok @Desc: Test List Running VM's ... === TestName: test_02_list_Running_vm | Status : SUCCESS === ok @Desc: Test List Stopped VM's ... === TestName: test_03_list_Stopped_vm | Status : SUCCESS === ok @Desc: Test List Destroyed VM's ... === TestName: test_04_list_Destroyed_vm | Status : SUCCESS === ok @Desc: Test List VM by Id ... === TestName: test_05_list_vm_by_id | Status : SUCCESS === ok @Desc: Test List VM's by Name ... === TestName: test_06_list_vm_by_name | Status : SUCCESS === ok @Desc: Test List VM's by Name and State ... === TestName: test_07_list_vm_by_name_state | Status : SUCCESS === ok @Desc: Test List VM by Zone. ... === TestName: test_08_list_vm_by_zone | Status : SUCCESS === ok @Desc: Test List VM by Zone. ... === TestName: test_09_list_vm_by_zone_name | Status : SUCCESS === ok @Desc: Test List VM by Zone. ... === TestName: test_10_list_vm_by_zone_name_state | Status : SUCCESS === ok Thanks, Chandan Purushothama
Re: Review Request 27049: CLOUDSTACK-7769 - Fixed test_ssvm.py script
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27049/#review57878 --- Ship it! Ship It! - sangeetha hariharan On Oct. 22, 2014, 7:19 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27049/ --- (Updated Oct. 22, 2014, 7:19 p.m.) Review request for cloudstack and sangeetha hariharan. Bugs: CLOUDSTACK-7769 https://issues.apache.org/jira/browse/CLOUDSTACK-7769 Repository: cloudstack-git Description --- SSVM and CPVM's gateway in EIP-ELB Setup is present in the Public Network and not in the private network. Hence needs to avoid that assertion in EIP-ELB Setup scenario. Diffs - test/integration/smoke/test_ssvm.py 5713569 Diff: https://reviews.apache.org/r/27049/diff/ Testing --- Testing done to see if the fix didnt break other configuration, as getting EIP-ELB setup ready is resource intensive: Test List secondary storage VMs ... === TestName: test_01_list_sec_storage_vm | Status : SUCCESS === ok Test List console proxy VMs ... === TestName: test_02_list_cpvm_vm | Status : SUCCESS === ok Thanks, Chandan Purushothama
Review Request 27000: CLOUDSTACK-7762 -[Automation] - Fix test failure for test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27000/
---
Review request for cloudstack, anthony xu and Chandan Purushothama.
Bugs: CLOUDSTACK-7762
https://issues.apache.org/jira/browse/CLOUDSTACK-7762
Repository: cloudstack-git
Description
---
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py fails in BVT runs
with the following exception:
2014-10-20 16:41:00,497 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-120:ctx-83b738d9 job-459) Add job-459 into job monitoring
2014-10-20 16:41:00,497 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-120:ctx-83b738d9 job-459) Executing AsyncJobVO {id:459,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin,
cmdInfo: {response:json,ctxDetails:
{\com.cloud.vm.snapshot.VMSnapshot\:\12280973-a1e4-43e3-80b3-3afacd607909\}
,cmdEventType:VMSNAPSHOT.REVERTTO,ctxUserId:2,httpmethod:GET,vmsnapshotid:12280973-a1e4-43e3-80b3-3afacd607909,ctxAccountId:2,ctxStartEventId:1406,apiKey:aJwkScf5ziRwz8gKQ9HB0Ce6hSsTJTUtmUDUQ_U2teV3vVmuLQRLad8xqAgr7CrFOEQbywdVpKSt2yC_ORXLYg,signature:cYBxgg8eBfktovmCaHYox2xoTE8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 11489258594360, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-20 16:41:00,529 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-120:ctx-83b738d9 job-459) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin
com.cloud.exception.InvalidParameterValueException: VM Snapshot revert not
allowed. This will result in VM state change. You can revert running VM to disk
and memory type snapshot and stopped VM to disk type snapshot
at
com.cloud.vm.snapshot.VMSnapshotManagerImpl.revertToSnapshot(VMSnapshotManagerImpl.java:581)
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:601)
Root Cause :
reverting Snapshots is allowed only when there is no vm state change associated
with it.
Following are the 2 scenarios allowed:
1.Revert a Running VM to a Disk and Memory Snapshot ( with and without
quiesce option).
2.Revert a Stopped VM to a Disk Snapshot ( with and without quiesce
option).
In this test case , we are testing reverting to a Disk Snapshot. Introduced a
Vm stop before performing the revert operation.
Diffs
-
test/integration/smoke/test_vm_snapshots.py 131da99
Diff: https://reviews.apache.org/r/27000/diff/
Testing
---
Tested with advanced zone set up with Xenserver hosts:
Test to create VM snapshots ... === TestName: test_01_create_vm_snapshots |
Status : SUCCESS ===
ok
Test to revert VM snapshots ... === TestName: test_02_revert_vm_snapshots |
Status : SUCCESS ===
ok
Test to delete vm snapshots ... === TestName: test_03_delete_vm_snapshots |
Status : SUCCESS ===
ok
--
Ran 3 tests in 795.005s
OK
Thanks,
sangeetha hariharan
Review Request 25841: CLOUDSTACK-7587 - Automation - Add simulator_only attribute to acl related test cases.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25841/ --- Review request for cloudstack, Alex Brett, Chandan Purushothama, Min Chen, and Santhosh Edukulla. Repository: cloudstack-git Description --- Added simulator_only attribute to all the acl related test cases , so that they do not get picked up by the hypervisor runs bu get picked only for the simulator runs. Diffs - test/integration/component/test_acl_isolatednetwork.py 59119f1 test/integration/component/test_acl_isolatednetwork_delete.py 3d09390 test/integration/component/test_acl_listsnapshot.py ac8748d test/integration/component/test_acl_listvm.py 398f98a test/integration/component/test_acl_listvolume.py e527582 test/integration/component/test_acl_sharednetwork.py 5d57f30 test/integration/component/test_acl_sharednetwork_deployVM-impersonation.py a05a2d8 Diff: https://reviews.apache.org/r/25841/diff/ Testing --- Tested by making sure that when -a !simulator_only,tags=advanced,required_hardware=false is used for the acl related test suites , not test case gets executed. Thanks, sangeetha hariharan
Review Request 25796: CLOUDSTACK-7585 - Automation - Fix test_acl_sharednetwork.py and test_acl_sharednetwork_deployVM-impersonation.py to pick Shared Network network offering when creating networks
| ++--+--+--+--+-+-+--+--+-+--+-+---+-+-+-+--+--+---+--+--+-+++-++---++---+-+---+---+++--+ 1 row in set (0.00 sec) mysqlselect id,name,network_offering_id from networks; | 419 | SharedNetwork-All| 7 | | 420 | SharedNetwork-Domain-nosubdomain | 7 | | 421 | SharedNetwork-Domain-withsubdomain | 7 | | 422 | SharedNetwork-Account| 7 | | 423 | SharedNetwork-All-impersonation | 7 | | 424 | SharedNetwork-Domain-nosubdomain-impersonation | 7 | | 425 | SharedNetwork-Domain-withsubdomain-impersonation | 7 | | 426 | SharedNetwork-Account-impersonation | 7 | +-+--+-+ Thanks, sangeetha hariharan
Re: Review Request 25518: CLOUDSTACK-7035-[Automation] - Automate ACL test cases relating to listNetworks() for isolated and shared networks.
uuid in id parameter ... === TestName: test_listNetwork_by_id_as_user_vmsfromotherdomain | Status : SUCCESS === ok Ran 95 tests in 147.009s FAILED (failures=11) Following bugs have been logged to track the 11 failures seen in this run: CLOUDSTACK-6974 - IAM-Root Admin - When listNetwork is used with listall=false (or no listall passed), all isoalted networks belonging to other users is listed. CLOUDSTACK-6973 -I AM - listNetworks - When Domain Admin calls listNetwork with listall=false , isolated networks belonging to other users in the domain is also listed. CLOUDSTACK-6939 - IAM - DomainAdmin - Not able to listNetwork belonging to a subdomain by passing uuid. CLOUDSTACK-6937- IAM - ROOT admin - Not able to list network owned by accounts under any domain by passing uuid. Thanks, sangeetha hariharan
Re: Review Request 25749: Fixed CLOUDSTACK-7573: ISO Guest OS Change
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25749/#review53756 --- Ship it! Ship It! - sangeetha hariharan On Sept. 17, 2014, 7:28 p.m., Chandan Purushothama wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25749/ --- (Updated Sept. 17, 2014, 7:28 p.m.) Review request for cloudstack, Amogh Vasekar, sangeetha hariharan, and sanjeev n. Bugs: CLOUDSTACK-7573 https://issues.apache.org/jira/browse/CLOUDSTACK-7573 Repository: cloudstack-git Description --- The Bug results in VM deployment failure across different configurations. Correcting the guest OS Type resolves the issue Diffs - tools/marvin/marvin/config/test_data.py 9b2aee7 Diff: https://reviews.apache.org/r/25749/diff/ Testing --- I tested manually on a different setup. Thanks, Chandan Purushothama
Review Request 25722: CLOUDSTACK-7567 - Automate ACL test cases relating to depoying VM in shared network with different scopes - All/Domain/Domain with subdomain/Account for Admin, domain admin and r
Validate that user in the parent domain is NOT allowed to deploy VM in a shared network created with scope=domain and no subdomain access ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_nosubdomainaccess_parentdomainuser | Status : SUCCESS === ok Validate that admin user in a subdomain is NOT allowed to deploy VM in a shared network created with scope=domain and no subdomain access ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_nosubdomainaccess_subdomainadminuser | Status : SUCCESS === ok Validate that regular user in a subdomain is NOT allowed to deploy VM in a shared network created with scope=domain and no subdomain access ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_nosubdomainaccess_subdomainuser | Status : SUCCESS === ok Validate that admin user in ROOT domain is NOT allowed to deploy VM in a shared network created with scope=domain and with subdomain access for any domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_ROOTadmin | Status : SUCCESS === ok Validate that regular user in ROOT domain is NOT allowed to deploy VM in a shared network created with scope=domain and with subdomain access for any domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_ROOTuser | Status : SUCCESS === ok Validate that admin user in a domain is allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_domainadminuser | Status : SUCCESS === ok Validate that regular user in a domain is allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_domainuser | Status : SUCCESS === ok Validate that admin user in a parent domain is NOT allowed to deploy VM in a shared network created with scope=domain and with subdomain access for any domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_parentdomainadminuser | Status : SUCCESS === ok Validate that regular user in a parent domain is NOT allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_parentdomainuser | Status : SUCCESS === ok Validate that an admin user in a subdomain is allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the parent domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_subdomainadminuser | Status : SUCCESS === ok Validate that regular user in a subdomain is allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the parent domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_subdomainuser | Status : SUCCESS === ok -- Ran 28 tests in 125.258s OK Thanks, sangeetha hariharan
Re: Review Request 22713: This Test suite has test cases for deploying Virtual Machine using impersonation (passing account and domainId parameters) for shared network
: test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_parentdomainadminuser | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_parentdomainuser (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_parentdomainuser | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainadminuser (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainadminuser | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainuser (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainuser | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_regularuser_scope_all_anotherusersamedomain (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_regularuser_scope_all_anotherusersamedomain | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_regularuser_scope_all_crossdomain (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_regularuser_scope_all_crossdomain | Status : SUCCESS === ok -- Ran 51 tests in 197.482s OK Thanks, sangeetha hariharan
Review Request 25518: CLOUDSTACK-7035-[Automation] - Automate ACL test cases relating to listNetworks() for isolated and shared networks.
isoalted networks belonging to other users is listed. CLOUDSTACK-6973 -I AM - listNetworks - When Domain Admin calls listNetwork with listall=false , isolated networks belonging to other users in the domain is also listed. CLOUDSTACK-6939 - IAM - DomainAdmin - Not able to listNetwork belonging to a subdomain by passing uuid. CLOUDSTACK-6937- IAM - ROOT admin - Not able to list network owned by accounts under any domain by passing uuid. Thanks, sangeetha hariharan
Re: Review Request 22707: Test suite contains test cases relating to access checks for listSnapshot() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain ad
) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersindomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_own (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_own | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromotherdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromotherdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 197.637s OK Thanks, sangeetha hariharan
Re: Review Request 22712: This Test suite has test cases relating to acess checks for deleteNetwork() for Admin, domain admin and regular users
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22712/ --- (Updated Sept. 9, 2014, 8:39 p.m.) Review request for cloudstack, Min Chen, Prachi Damle, and Santhosh Edukulla. Changes --- Removed # from comments that are already encampassed with in block Repository: cloudstack-git Description --- This Test suite has test cases relating to acess checks for deleteNetwork() for Admin, domain admin and regular users Diffs (updated) - test/integration/component/test_acl_isolatednetwork_delete.py PRE-CREATION Diff: https://reviews.apache.org/r/22712/diff/ Testing --- Test Suite was executed against a management server built from 4.4-forward branch using a simulator set up: test_deleteNetwork_admin (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin | Status : SUCCESS === ok test_deleteNetwork_admin_foruserinotherdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin_foruserinotherdomain | Status : SUCCESS === ok test_deleteNetwork_admin_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin_foruserinsamedomain | Status : SUCCESS === ok test_deleteNetwork_domaindmin (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin | Status : SUCCESS === ok test_deleteNetwork_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_deleteNetwork_domaindmin_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_foruserinsamedomain | Status : SUCCESS === ok test_deleteNetwork_domaindmin_foruserinsubdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_foruserinsubdomain | Status : SUCCESS === ok test_deleteNetwork_user (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user | Status : SUCCESS === ok test_deleteNetwork_user_foruserinotherdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user_foruserinotherdomain | Status : SUCCESS === ok test_deleteNetwork_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user_foruserinsamedomain | Status : SUCCESS === ok -- Ran 10 tests in 61.766s OK Thanks, sangeetha hariharan
Re: Review Request 22712: This Test suite has test cases relating to acess checks for deleteNetwork() for Admin, domain admin and regular users
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22712/ --- (Updated Sept. 8, 2014, 7:52 p.m.) Review request for cloudstack, Min Chen, Prachi Damle, and Santhosh Edukulla. Changes --- Moved out the data used by test suite from Sevices object with in the test suite to test_data.py Changed the tags for test cases - required_hardware=false to be picked up by simulator runs. Repository: cloudstack-git Description --- This Test suite has test cases relating to acess checks for deleteNetwork() for Admin, domain admin and regular users Diffs (updated) - test/integration/component/test_acl_isolatednetwork_delete.py PRE-CREATION Diff: https://reviews.apache.org/r/22712/diff/ Testing (updated) --- Test Suite was executed against a management server built from 4.4-forward branch using a simulator set up: test_deleteNetwork_admin (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin | Status : SUCCESS === ok test_deleteNetwork_admin_foruserinotherdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin_foruserinotherdomain | Status : SUCCESS === ok test_deleteNetwork_admin_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin_foruserinsamedomain | Status : SUCCESS === ok test_deleteNetwork_domaindmin (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin | Status : SUCCESS === ok test_deleteNetwork_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_deleteNetwork_domaindmin_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_foruserinsamedomain | Status : SUCCESS === ok test_deleteNetwork_domaindmin_foruserinsubdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_foruserinsubdomain | Status : SUCCESS === ok test_deleteNetwork_user (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user | Status : SUCCESS === ok test_deleteNetwork_user_foruserinotherdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user_foruserinotherdomain | Status : SUCCESS === ok test_deleteNetwork_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user_foruserinsamedomain | Status : SUCCESS === ok -- Ran 10 tests in 61.766s OK Thanks, sangeetha hariharan
Re: Review Request 22707: Test suite contains test cases relating to access checks for listSnapshot() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain ad
: test_listSnapshot_as_rootadmin_rec_true | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersindomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersindomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_own (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_own | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromotherdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromotherdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 197.637s OK Thanks, sangeetha hariharan
Re: Review Request 22706: This test suite contains test cases relating to access checks for listVolume() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain
: test_listVolume_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listVolume_by_id_as_domainadmin_owns (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_Volumesownedbyothers (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_Volumesownedbyothers | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_owns (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_user_own (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_own | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromotherdomain (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromotherdomain | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 139.480s OK Thanks, sangeetha hariharan
Re: Review Request 22705: Test cases relating to access checks for listVirtualMachine() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain admin and regula
: test_listVM_as_rootadmin_domainid_listall_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_false_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_false_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_false_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_false_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_rec_true | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersindomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersindomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_owns (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVM_by_id_as_rootadmin_Vmsownedbyothers (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_rootadmin_Vmsownedbyothers | Status : SUCCESS === ok test_listVM_by_id_as_rootadmin_owns (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVM_by_id_as_user_own (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_own | Status : SUCCESS === ok test_listVM_by_id_as_user_vmfromsamedomaindifferentaccount (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_vmfromsamedomaindifferentaccount | Status : SUCCESS === ok test_listVM_by_id_as_user_vmsfromotherdomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_vmsfromotherdomain | Status : SUCCESS === ok -- Ran 95 tests in 134.796s OK Thanks, sangeetha hariharan
Re: Review Request 22705: Test cases relating to access checks for listVirtualMachine() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain admin and regula
(integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_false_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_false_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_false_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_rec_true | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersindomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersindomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_owns (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVM_by_id_as_rootadmin_Vmsownedbyothers (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_rootadmin_Vmsownedbyothers | Status : SUCCESS === ok test_listVM_by_id_as_rootadmin_owns (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVM_by_id_as_user_own (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_own | Status : SUCCESS === ok test_listVM_by_id_as_user_vmfromsamedomaindifferentaccount (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_vmfromsamedomaindifferentaccount | Status : SUCCESS === ok test_listVM_by_id_as_user_vmsfromotherdomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_vmsfromotherdomain | Status : SUCCESS === ok -- Ran 95 tests in 134.796s OK Thanks, sangeetha hariharan
Re: Review Request 22706: This test suite contains test cases relating to access checks for listVolume() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain
: test_listVolume_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listVolume_by_id_as_domainadmin_owns (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_Volumesownedbyothers (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_Volumesownedbyothers | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_owns (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_user_own (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_own | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromotherdomain (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromotherdomain | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 139.480s OK Thanks, sangeetha hariharan
RE: Snapshot partial file creates are not cleaned up.
Hi, Following are couple of issues that have been logged to track this issue: CLOUDSTACK-5395 - When backup snapshot fails because of backup.snapshot.wait time exceeding , the vhd entries form the primary store is not getting cleared. This bug was reopened to address - cleaning up of snapshot that errors out from primary store and secondary store specific to KVM hypervisor. CLOUDSTACK-5446 - KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason there is other active snapshot tasks on the instance to which the volume is attached Thanks Sangeetha -Original Message- From: Amin Samir [mailto:a...@opencloud.net.au] Sent: Monday, August 18, 2014 9:55 PM To: dev@cloudstack.apache.org Subject: Snapshot partial file creates are not cleaned up. Hello, When a volume snapshot creation times out ( based on the global setting), the partial file creates is not cleaned up. Has anyone faced this? Or filled a bug for this? Kind Regards
Re: Review Request 22709: This test suite contains test cases relating to access checks for createNetwork(), deploying VM in an isolated network and restartNetwork() for Admin, domain admin and regula
: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_parentdomainuser | Status : SUCCESS === ok # Validate that an admin user in a subdomain is allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the parent domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_subdomainadminuser | Status : SUCCESS === ok # Validate that regular user in a subdomain is allowed to deploy VM in a shared network created with scope=domain and with subdomain access for the parent domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_subdomainuser | Status : SUCCESS === ok -- Ran 28 tests in 129.477s OK Thanks, sangeetha hariharan
Re: Review Request 22709: This test suite contains test cases relating to access checks for createNetwork(), deploying VM in an isolated network and restartNetwork() for Admin, domain admin and regula
and with subdomain access for the parent domain ... === TestName: test_deployVM_in_sharedNetwork_scope_domain_withsubdomainaccess_subdomainuser | Status : SUCCESS === ok -- Ran 28 tests in 129.477s OK Thanks, sangeetha hariharan
Re: Review Request 22709: This test suite contains test cases relating to access checks for createNetwork(), deploying VM in an isolated network and restartNetwork() for Admin, domain admin and regula
On June 18, 2014, 3:20 p.m., Santhosh Edukulla wrote: test/integration/component/test_acl_isolatednetwork.py, line 481 https://reviews.apache.org/r/22709/diff/1/?file=612001#file612001line481 Lot of entities got created, is clean up happening for all of them? I mean can we double check post running the script from ms server that nothing was left out, either offerings, vms, accounts etc. All the resources like accounts,Vms are all created under 2 domains except for 2 accounts created under ROOT domain which are included in the cleanup object that is sent to cleanup_resources method. In tearDownClass, I am deleting both the domains that were created with clean option set to true which I have made sure as part of test execution cleans up all resources under this domain: cls.cleanup = [ cls.account_root, cls.account_roota, cls.service_offering, ] In tearDownClass() cls.domain_1.delete(cls.apiclient,cleanup=true) cls.domain_2.delete(cls.apiclient,cleanup=true) cleanup_resources(cls.apiclient, cls.cleanup) On June 18, 2014, 3:20 p.m., Santhosh Edukulla wrote: test/integration/component/test_acl_isolatednetwork.py, line 938 https://reviews.apache.org/r/22709/diff/1/?file=612001#file612001line938 Is it as well a fail scenario if expected exception message is not in the response? Question: Is receiving an exception message is important or its content as well? This use case is to validate that Domain admin should not be able allowed to deploy vm for users not in his sub domain. We expect the API to error out with a specific error message relating to access check failure. So it is important that we receive an exception with a certain access check failure message. On June 18, 2014, 3:20 p.m., Santhosh Edukulla wrote: test/integration/component/test_acl_isolatednetwork.py, line 939 https://reviews.apache.org/r/22709/diff/1/?file=612001#file612001line939 Move this inside try block. As well, use self.fail instead of this,it looks neat to read. In this case , test case fails when exception is not raised. That is the reason why I have the raise AssertionError out side the try block. I will use self.fail instead of raising a AssertionError On June 18, 2014, 3:20 p.m., Santhosh Edukulla wrote: test/integration/component/test_acl_isolatednetwork.py, line 35 https://reviews.apache.org/r/22709/diff/1/?file=612001#file612001line35 Move this to test data under marvin/config directory, if possible. The test data I am using for acl related suites are very large and does not overlap with any test data used by all other suites. So my thinking is that it would not be ideal to add it to the common file - test_data.py which is common to all test suites. Is there a way for me to create a test data file specific for acl test cases and have my test suite load this specific test data? For this patch I have kept the data within the test suite itself. On June 18, 2014, 3:20 p.m., Santhosh Edukulla wrote: test/integration/component/test_acl_isolatednetwork.py, line 935 https://reviews.apache.org/r/22709/diff/1/?file=612001#file612001line935 Is it possible to define all exception entities in CloudStackException and check for them? Otherwise maintenance will be a bit difficult if we just search for message? As well, convert to lower() and search. I will define all the exception entities in codes.py and have a method verifyMsginException(exception,message) which will verify that the exception has the message. On June 18, 2014, 3:20 p.m., Santhosh Edukulla wrote: test/integration/component/test_acl_isolatednetwork.py, line 936 https://reviews.apache.org/r/22709/diff/1/?file=612001#file612001line936 Better thing is to localize all these check in to a function and pass exception object and message to verify, define all your exception messages in class and verify by passing them. EX: class ExampleExceptionsToVerify: ABC=verify abc BCD=verify bcd verifyMsginException(e,ExampleExceptionsToVerify.ABC). This way, all messages can be handled in one single function and maintenance will be easy? I will define all the exception entities in codes.py and have a method verifyMsginException(exception,message) which will verify that the exception has the message. - sangeetha --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22709/#review46074 --- On June 18, 2014, 1:28 a.m., sangeetha hariharan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22709
Re: Review Request 22709: This test suite contains test cases relating to access checks for createNetwork(), deploying VM in an isolated network and restartNetwork() for Admin, domain admin and regula
(integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_17_deployvm_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_18_deployvm_user (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_18_deployvm_user | Status : SUCCESS === ok test_19_deployvm_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_19_deployvm_user_foruserinsamedomain | Status : SUCCESS === ok test_20_1_deployvm_user_incrossnetwork (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_20_1_deployvm_user_incrossnetwork | Status : SUCCESS === ok test_20_deployvm_user_foruserincrossdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_20_deployvm_user_foruserincrossdomain | Status : SUCCESS === ok test_21_restartNetwork_admin (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_21_restartNetwork_admin | Status : SUCCESS === ok test_22_restartNetwork_admin_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_22_restartNetwork_admin_foruserinsamedomain | Status : SUCCESS === ok test_23_restartNetwork_admin_foruserinotherdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_23_restartNetwork_admin_foruserinotherdomain | Status : SUCCESS === ok test_24_restartNetwork_domaindmin (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_24_restartNetwork_domaindmin | Status : SUCCESS === ok test_25_restartNetwork_domaindmin_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_25_restartNetwork_domaindmin_foruserinsamedomain | Status : SUCCESS === ok test_26_restartNetwork_domaindmin_foruserinsubdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_26_restartNetwork_domaindmin_foruserinsubdomain | Status : SUCCESS === ok test_27_restartNetwork_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_27_restartNetwork_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_28_restartNetwork_user (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_28_restartNetwork_user | Status : SUCCESS === ok test_29_restartNetwork_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_29_restartNetwork_user_foruserinsamedomain | Status : SUCCESS === ok test_30_restartNetwork_user_foruserinotherdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_30_restartNetwork_user_foruserinotherdomain | Status : SUCCESS === ok -- Ran 33 tests in 256.713s OK Thanks, sangeetha hariharan
Re: Review Request 22709: This test suite contains test cases relating to access checks for createNetwork(), deploying VM in an isolated network and restartNetwork() for Admin, domain admin and regula
test_17_deployvm_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_17_deployvm_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_18_deployvm_user (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_18_deployvm_user | Status : SUCCESS === ok test_19_deployvm_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_19_deployvm_user_foruserinsamedomain | Status : SUCCESS === ok test_20_1_deployvm_user_incrossnetwork (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_20_1_deployvm_user_incrossnetwork | Status : SUCCESS === ok test_20_deployvm_user_foruserincrossdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_20_deployvm_user_foruserincrossdomain | Status : SUCCESS === ok test_21_restartNetwork_admin (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_21_restartNetwork_admin | Status : SUCCESS === ok test_22_restartNetwork_admin_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_22_restartNetwork_admin_foruserinsamedomain | Status : SUCCESS === ok test_23_restartNetwork_admin_foruserinotherdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_23_restartNetwork_admin_foruserinotherdomain | Status : SUCCESS === ok test_24_restartNetwork_domaindmin (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_24_restartNetwork_domaindmin | Status : SUCCESS === ok test_25_restartNetwork_domaindmin_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_25_restartNetwork_domaindmin_foruserinsamedomain | Status : SUCCESS === ok test_26_restartNetwork_domaindmin_foruserinsubdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_26_restartNetwork_domaindmin_foruserinsubdomain | Status : SUCCESS === ok test_27_restartNetwork_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_27_restartNetwork_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_28_restartNetwork_user (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_28_restartNetwork_user | Status : SUCCESS === ok test_29_restartNetwork_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_29_restartNetwork_user_foruserinsamedomain | Status : SUCCESS === ok test_30_restartNetwork_user_foruserinotherdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_30_restartNetwork_user_foruserinotherdomain | Status : SUCCESS === ok -- Ran 33 tests in 256.713s OK Thanks, sangeetha hariharan
Review Request 22705: Test cases relating to access checks for listVirtualMachine() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain admin and regular us
: test_listVM_as_rootadmin_domainid_listall_false_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_false_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_false_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_listall_true_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_listall_true_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_domainid_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_domainid_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_false_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_false_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_listall_true_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_listall_true_rec_true | Status : SUCCESS === ok test_listVM_as_rootadmin_rec_false (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_rec_false | Status : SUCCESS === ok test_listVM_as_rootadmin_rec_true (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_as_rootadmin_rec_true | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersindomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersindomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listVM_by_id_as_domainadmin_owns (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVM_by_id_as_rootadmin_Vmsownedbyothers (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_rootadmin_Vmsownedbyothers | Status : SUCCESS === ok test_listVM_by_id_as_rootadmin_owns (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVM_by_id_as_user_own (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_own | Status : SUCCESS === ok test_listVM_by_id_as_user_vmfromsamedomaindifferentaccount (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_vmfromsamedomaindifferentaccount | Status : SUCCESS === ok test_listVM_by_id_as_user_vmsfromotherdomain (integration.component.test_acl_listvm.TestVMList) ... === TestName: test_listVM_by_id_as_user_vmsfromotherdomain | Status : SUCCESS === ok -- Ran 95 tests in 134.796s OK Thanks, sangeetha hariharan
Review Request 22706: This test suite contains test cases relating to access checks for listVolume() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain adm
(integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_Volumesownedbyothers (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_Volumesownedbyothers | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_owns (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_user_own (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_own | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromotherdomain (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromotherdomain | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 139.480s OK Thanks, sangeetha hariharan
Re: Review Request 22706: This test suite contains test cases relating to access checks for listVolume() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain
(integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_Volumesownedbyothers (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_Volumesownedbyothers | Status : SUCCESS === ok test_listVolume_by_id_as_rootadmin_owns (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listVolume_by_id_as_user_own (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_own | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromotherdomain (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromotherdomain | Status : SUCCESS === ok test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount (integration.component.test_acl_listvolume.TestVolumeList) ... === TestName: test_listVolume_by_id_as_user_volumefromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 139.480s OK Thanks, sangeetha hariharan
Review Request 22707: Test suite contains test cases relating to access checks for listSnapshot() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain admin
test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_own (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_own | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromotherdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromotherdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 197.637s OK Thanks, sangeetha hariharan
Re: Review Request 22707: Test suite contains test cases relating to access checks for listSnapshot() with parameters - id, listall, isrecursive, account and domainid executed as ROOT admin, domain ad
test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersinsubdomain2 | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_ownedbyusersnotindomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_domainadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_domainadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_Snapshotsownedbyothers | Status : SUCCESS === ok test_listSnapshot_by_id_as_rootadmin_owns (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_rootadmin_owns | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_own (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_own | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromotherdomain (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromotherdomain | Status : SUCCESS === ok test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount (integration.component.test_acl_listsnapshot.TestSnapshotList) ... === TestName: test_listSnapshot_by_id_as_user_snapshotfromsamedomaindifferentaccount | Status : SUCCESS === ok -- Ran 95 tests in 197.637s OK Thanks, sangeetha hariharan
Review Request 22709: This test suite contains test cases relating to access checks for createNetwork(), deploying VM in an isolated network and restartNetwork() for Admin, domain admin and regular us
(integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_20_1_deployvm_user_incrossnetwork | Status : SUCCESS === ok test_20_deployvm_user_foruserincrossdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_20_deployvm_user_foruserincrossdomain | Status : SUCCESS === ok test_21_restartNetwork_admin (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_21_restartNetwork_admin | Status : SUCCESS === ok test_22_restartNetwork_admin_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_22_restartNetwork_admin_foruserinsamedomain | Status : SUCCESS === ok test_23_restartNetwork_admin_foruserinotherdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_23_restartNetwork_admin_foruserinotherdomain | Status : SUCCESS === ok test_24_restartNetwork_domaindmin (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_24_restartNetwork_domaindmin | Status : SUCCESS === ok test_25_restartNetwork_domaindmin_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_25_restartNetwork_domaindmin_foruserinsamedomain | Status : SUCCESS === ok test_26_restartNetwork_domaindmin_foruserinsubdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_26_restartNetwork_domaindmin_foruserinsubdomain | Status : SUCCESS === ok test_27_restartNetwork_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_27_restartNetwork_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_28_restartNetwork_user (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_28_restartNetwork_user | Status : SUCCESS === ok test_29_restartNetwork_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_29_restartNetwork_user_foruserinsamedomain | Status : SUCCESS === ok test_30_restartNetwork_user_foruserinotherdomain (integration.component.test_acl_isolatednetwork.TestIsolatedNetwork) ... === TestName: test_30_restartNetwork_user_foruserinotherdomain | Status : SUCCESS === ok -- Ran 33 tests in 256.713s OK Thanks, sangeetha hariharan
Review Request 22712: This Test suite has test cases relating to acess checks for deleteNetwork() for Admin, domain admin and regular users
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22712/ --- Review request for cloudstack, Min Chen, Prachi Damle, and Santhosh Edukulla. Repository: cloudstack-git Description --- This Test suite has test cases relating to acess checks for deleteNetwork() for Admin, domain admin and regular users Diffs - test/integration/component/test_acl_isolatednetwork_delete.py PRE-CREATION Diff: https://reviews.apache.org/r/22712/diff/ Testing --- Test Suite was executed against a management server built from 4.4-forward branch using a simulator set up: test_deleteNetwork_admin (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin | Status : SUCCESS === ok test_deleteNetwork_admin_foruserinotherdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin_foruserinotherdomain | Status : SUCCESS === ok test_deleteNetwork_admin_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_admin_foruserinsamedomain | Status : SUCCESS === ok test_deleteNetwork_domaindmin (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin | Status : SUCCESS === ok test_deleteNetwork_domaindmin_forcrossdomainuser (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_forcrossdomainuser | Status : SUCCESS === ok test_deleteNetwork_domaindmin_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_foruserinsamedomain | Status : SUCCESS === ok test_deleteNetwork_domaindmin_foruserinsubdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_domaindmin_foruserinsubdomain | Status : SUCCESS === ok test_deleteNetwork_user (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user | Status : SUCCESS === ok test_deleteNetwork_user_foruserinotherdomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user_foruserinotherdomain | Status : SUCCESS === ok test_deleteNetwork_user_foruserinsamedomain (integration.component.test_acl_isolatednetwork_delete.TestIsolatedNetworkDelete) ... === TestName: test_deleteNetwork_user_foruserinsamedomain | Status : SUCCESS === ok -- Ran 10 tests in 61.766s OK Thanks, sangeetha hariharan
Review Request 22713: This Test suite has test cases for deploying Virtual Machine using impersonation (passing account and domainId parameters) for shared network
: test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainadminuser | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainuser (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_domainadmin_scope_domain_withsubdomainaccess_subdomainuser | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_regularuser_scope_all_anotherusersamedomain (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_regularuser_scope_all_anotherusersamedomain | Status : SUCCESS === ok test_deployVM_in_sharedNetwork_as_regularuser_scope_all_crossdomain (integration.component.test_acl_sharednetwork_deployVM-impersonation.TestSharedNetwork) ... === TestName: test_deployVM_in_sharedNetwork_as_regularuser_scope_all_crossdomain | Status : SUCCESS === ok -- Ran 51 tests in 197.482s OK Thanks, sangeetha hariharan
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
Nux, - I created an instance - I added a rule (ping) in the otherwise untouched default security group - I added a rule (ping) in the otherwise untouched default security group Result: I could not ping the instance In this case , is it possible that when you tried to ping the instance , the instance had not booted completely? Thanks Sangeetha -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Saturday, March 15, 2014 4:02 AM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 15.03.2014 00:42, Edison Su wrote: From my test, all the rules got applied. If you stop/start vm, will the first rule get applied? Let's for QA team's testing. Hi Edison, So I've found out when the first rule doesn't get applied. Test 1: I started with - cloudstack-agent freshly restarted - I created an instance - I added a rule (ping) in the otherwise untouched default security group Result: I could not ping the instance Once I added another rule the ping rule also got applied. Test 2: - deleted the above instance and cleared the default security group - created new instance - added a rule for ping again Result: I could ping the instance So this is an issue that happens just after cloudstack-agent was started, once the security groups have processed a couple of rules then all goes as expected. I don't know what to make of this.. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: New Committer: Sanjeev Neelarapu
Congratulations Sanjeev! -Sangeetha -Original Message- From: Somesh Naidu [mailto:somesh.na...@citrix.com] Sent: Thursday, November 14, 2013 7:31 AM To: dev@cloudstack.apache.org Subject: RE: New Committer: Sanjeev Neelarapu Congratulations Sanjeev! Regards, Somesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, November 14, 2013 4:15 PM To: dev Subject: Re: New Committer: Sanjeev Neelarapu welcome Sanjeev and good luck. On Thu, Nov 14, 2013 at 10:26 AM, Rajani Karuturi rajani.karut...@citrix.com wrote: Congratulations Sanjeev. -- - Rajani -Original Message- From: Sateesh Chodapuneedi sateesh.chodapune...@citrix.commailto:Sateesh%20Chodapuneedi%20%3csa teesh.chodapune...@citrix.com%3e Reply-to: dev@cloudstack.apache.org To: dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:%22...@cloudstack.apache.org%22%20%3 c...@cloudstack.apache.org%3e Subject: RE: New Committer: Sanjeev Neelarapu Date: Thu, 14 Nov 2013 07:40:29 + Sanjeev, Hearty Congratulations, great job. Regards, Sateesh -Original Message- From: Du Jun [mailto:dj199...@gmail.com] Sent: 14 November 2013 12:27 To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: New Committer: Sanjeev Neelarapu Congratulations! -- Best regards. Frank 2013/11/14 Koushik Das koushik@citrix.commailto:koushik@citrix.com Congrats Sanjeev On 14-Nov-2013, at 11:29 AM, Prasanna Santhanam t...@apache.orgmailto:t...@apache.org wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Sanjeev Neelarapu to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Sanjeev! -- Prasanna., on behalf of the Apache CloudStack PMC Powered by BigRock.com
RE: [ANNOUNCE] New Committer: Krishnan, Sowmya
Congrats Sowmya! -Original Message- From: Koushik Das [mailto:koushik@citrix.com] Sent: Wednesday, October 23, 2013 8:43 AM To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] New Committer: Krishnan, Sowmya Congrats Sowmya! On 23-Oct-2013, at 4:16 PM, Prasanna Santhanam t...@apache.org wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Sowmya Krishnan to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Sowmya! -- Prasanna., on behalf of the Apache CloudStack PMC Powered by BigRock.com
RE: [ANNOUNCE] New Committer: Shilamkar, Girish
Congrats Girish!! -Original Message- From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] Sent: Wednesday, October 23, 2013 3:59 AM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] New Committer: Shilamkar, Girish Congratz, Girish -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Wednesday, October 23, 2013 4:08 PM To: CloudStack Dev Subject: [ANNOUNCE] New Committer: Shilamkar, Girish The Project Management Committee (PMC) for Apache CloudStack has asked Girish Shilamkar to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Girish! -- Prasanna., on behalf of the Apache CloudStack PMC Powered by BigRock.com
RE: [ANNOUNCE] New Committer: Talluri, Srikanteswara
Congrats Talluri!! -Original Message- From: Suresh Sadhu [mailto:suresh.sa...@citrix.com] Sent: Wednesday, October 23, 2013 4:16 AM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] New Committer: Talluri, Srikanteswara Congrats Talluri -Original Message- From: Sanjeev Neelarapu [mailto:sanjeev.neelar...@citrix.com] Sent: 23 October 2013 16:13 To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] New Committer: Talluri, Srikanteswara Congrats Talluri !! -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Wednesday, October 23, 2013 4:08 PM To: CloudStack Dev Subject: [ANNOUNCE] New Committer: Talluri, Srikanteswara The Project Management Committee (PMC) for Apache CloudStack has asked Srikanteswara Talluri to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Talluri! -- Prasanna., on behalf of the Apache CloudStack PMC Powered by BigRock.com
Re: Review Request 14469: CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14469/#review27163 --- Ship it! Ship It! - sangeetha hariharan On Oct. 16, 2013, 2:27 p.m., Girish Shilamkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14469/ --- (Updated Oct. 16, 2013, 2:27 p.m.) Review request for cloudstack, Harikrishna Patnala and venkata swamy babu budumuru. Bugs: CLOUDSTACK-4637 https://issues.apache.org/jira/browse/CLOUDSTACK-4637 Repository: cloudstack-git Description --- Add logic to wait for router to boot. Diffs - test/integration/component/test_egress_fw_rules.py 5c18f9c Diff: https://reviews.apache.org/r/14469/diff/ Testing --- test_01_1_egress_fr1 (test_egress_fw_rules.TestEgressFWRules) Test By-default the communication from guest n/w to public n/w is NOT allowed. ... ok test_01_egress_fr1 (test_egress_fw_rules.TestEgressFWRules) Test By-default the communication from guest n/w to public n/w is allowed. ... ok test_02_1_egress_fr2 (test_egress_fw_rules.TestEgressFWRules) Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. ... ok test_02_egress_fr2 (test_egress_fw_rules.TestEgressFWRules) Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. ... ok test_03_1_egress_fr3 (test_egress_fw_rules.TestEgressFWRules) Test Communication blocked with network that is other than specified ... ok test_03_egress_fr3 (test_egress_fw_rules.TestEgressFWRules) Test Communication blocked with network that is other than specified ... ok test_04_1_egress_fr4 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule and check the Firewall_Rules DB table ... ok test_04_egress_fr4 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule and check the Firewall_Rules DB table ... ok test_05_1_egress_fr5 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule and check the IP tables ... ok test_05_egress_fr5 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule and check the IP tables ... ok test_06_1_egress_fr6 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule without CIDR ... ok test_06_egress_fr6 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule without CIDR ... ok test_07_1_egress_fr7 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule without End Port ... ok test_07_egress_fr7 (test_egress_fw_rules.TestEgressFWRules) Test Create Egress rule without End Port ... ok test_08_1_egress_fr8 (test_egress_fw_rules.TestEgressFWRules) Test Port Forwarding and Egress Conflict ... ok test_08_egress_fr8 (test_egress_fw_rules.TestEgressFWRules) Test Port Forwarding and Egress Conflict ... ok test_09_1_egress_fr9 (test_egress_fw_rules.TestEgressFWRules) Test Delete Egress rule ... ok test_09_egress_fr9 (test_egress_fw_rules.TestEgressFWRules) Test Delete Egress rule ... ok test_10_1_egress_fr10 (test_egress_fw_rules.TestEgressFWRules) Test Invalid CIDR and Invalid Port ranges ... ok test_10_egress_fr10 (test_egress_fw_rules.TestEgressFWRules) Test Invalid CIDR and Invalid Port ranges ... ok test_11_1_egress_fr11 (test_egress_fw_rules.TestEgressFWRules) Test Regression on Firewall + PF + LB + SNAT ... ok test_11_egress_fr11 (test_egress_fw_rules.TestEgressFWRules) Test Regression on Firewall + PF + LB + SNAT ... ok test_12_1_egress_fr12 (test_egress_fw_rules.TestEgressFWRules) Test Reboot Router ... ok test_13_1_egress_fr13 (test_egress_fw_rules.TestEgressFWRules) Test Redundant Router : Master failover ... ok test_13_egress_fr13 (test_egress_fw_rules.TestEgressFWRules) Test Redundant Router : Master failover ... ok -- Ran 26 tests in 15127.540s OK Thanks, Girish Shilamkar
Re: Review Request 14469: CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14469/#review26761 --- 1.Can you see make sure that introducing a delay of 3 minutes is actually resulting in all failed test cases to succeed ? There are multiple test cases in this test suite that have failed with the same exception. 2. I see that there are no validation checks done yet for the following tests that are being reported as success: test_05_egress_fr5 test_05_1_egress_fr5 test_08_egress_fr8 test_08_1_egress_fr8 3. For test_03_1_egress_fr3 , expected_result param value is changed from 100 to 0 for exec_script_on_user_vm. In this case documentation says deploy VM using network offering with egress policy false , but Vm is deployed with egress_policy=True which is the default. create_vm() should be called with egress_policy=False , to match the changes that is done for expected_result. - sangeetha hariharan On Oct. 3, 2013, 2:33 p.m., Girish Shilamkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14469/ --- (Updated Oct. 3, 2013, 2:33 p.m.) Review request for cloudstack, Harikrishna Patnala and venkata swamy babu budumuru. Bugs: CLOUDSTACK-4637 Repository: cloudstack-git Description --- Add logic to wait for router to boot. Diffs - test/integration/component/test_egress_fw_rules.py 5c18f9c Diff: https://reviews.apache.org/r/14469/diff/ Testing --- Thanks, Girish Shilamkar
RE: Connection Refused
You can try setting this global parameter- secstorage.allowed.internal.sites to allow for mirrors.liquidweb.com . Or , If you register the iso using the Ip address instead of mirrors.liquidweb.com , it should work as well. -Thanks Sangeetha -Original Message- From: Maurice Lawler [mailto:maurice.law...@me.com] Sent: Wednesday, October 02, 2013 5:31 PM To: Cloud Dev Subject: Connection Refused Sorry to bother again, What would cause this... --2013-10-03 00:28:07-- http://mirrors.liquidweb.com/CentOS/6.4/isos/x86_64/CentOS-6.4-x86_64-minimal.iso Resolving mirrors.liquidweb.com (mirrors.liquidweb.com)... 69.167.187.144 Connecting to mirrors.liquidweb.com (mirrors.liquidweb.com)|69.167.187.144|:80... failed: Connection refused. From what I know of this, doesn't the secondary storage obtain / hold such ISO's therefore it would be necessary for it to connect to the mirror to download. WHat would I need to alter to permit this permission. I've disabled both iptables / ebtables -- I verified I am able to ping the sites but getting connection refused still. Whereas, I am able to pull things down via FTP just not HTTP. Please advise. - Maurice
RE: Connection Refused
After changing the global variable , can you see if restarting the SSVM helps? -Thanks Sangeetha -Original Message- From: Maurice Lawler [mailto:maurice.law...@me.com] Sent: Wednesday, October 02, 2013 5:58 PM To: dev@cloudstack.apache.org; Sangeetha Hariharan Subject: Re: Connection Refused Thank you Sangeetha, I was able to register the ISO via IP address. However, adding the CDIR/s for it still did not permit me to register the ISO via hostname. Along with that, the default template didn't download either for this same issue. On 10/2/13, 8:39 PM, Sangeetha Hariharan wrote: You can try setting this global parameter- secstorage.allowed.internal.sites to allow for mirrors.liquidweb.com . Or , If you register the iso using the Ip address instead of mirrors.liquidweb.com , it should work as well. -Thanks Sangeetha -Original Message- From: Maurice Lawler [mailto:maurice.law...@me.com] Sent: Wednesday, October 02, 2013 5:31 PM To: Cloud Dev Subject: Connection Refused Sorry to bother again, What would cause this... --2013-10-03 00:28:07-- http://mirrors.liquidweb.com/CentOS/6.4/isos/x86_64/CentOS-6.4-x86_64- minimal.iso Resolving mirrors.liquidweb.com (mirrors.liquidweb.com)... 69.167.187.144 Connecting to mirrors.liquidweb.com (mirrors.liquidweb.com)|69.167.187.144|:80... failed: Connection refused. From what I know of this, doesn't the secondary storage obtain / hold such ISO's therefore it would be necessary for it to connect to the mirror to download. WHat would I need to alter to permit this permission. I've disabled both iptables / ebtables -- I verified I am able to ping the sites but getting connection refused still. Whereas, I am able to pull things down via FTP just not HTTP. Please advise. - Maurice
RE: Security Groups
If you are using Xenserver hosts , can you make sure you have the CSP packages installed? -Thanks Sangeetha -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, September 12, 2013 9:33 AM To: dev@cloudstack.apache.org Subject: Security Groups I posed this question in the user list, but I figured I would throw it out here as well...So If I have created a zone with the DefaultSharedNetworkOfferingWithSGService network offering, then created a VM using the default security group, which has 0 ingress rules, I should NOT be able to do things like PING that VM correct? The answer to the above question was answered correct...My next question is, in that case what are some things I could look at to see why it's not behaving as expected.
RE: Creating an instance with ssh key pair
To deploy Vm using ssh key pairs you will need to use a template that has SSH Key Gen Scripts in it. Only then you will be able to ssh into the instance using ssh key. -Thanks Sangeetha -Original Message- From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: Thursday, September 12, 2013 5:00 AM To: dev@cloudstack.apache.org Subject: Creating an instance with ssh key pair Hello all, If I create an instance providing ssh key pair while creation, and using a normal template from the cloudstack setup, then will the SSH to vm using the keyPairFlieLocation always work? Or the template which I am using for creating the instance has to be supporting SSH keys? as explained in 5.2.1 section at http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/using-sshkeys.html In short, Is the SSH using keyPairFileLocation - template dependent or will it always work if I provide ssh key pair while creating instance and use normal template? Regards, Gaurav
RE: Instructions to *consume* events in another region?
Currently , we have the following stated as known limitations in the FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions+Functional+Spec# Limitations 1. Account/User/Domain data propogation/sync has to be handled outside cloudstack 2. Only events will be generated by cloudstack -Thanks Sangeetha --Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, July 12, 2013 1:31 PM To: dev@cloudstack.apache.org Subject: Re: Instructions to *consume* events in another region? On Fri, Jul 12, 2013 at 4:27 PM, Sangeetha Hariharan sangeetha.hariha...@citrix.com wrote: Management server can be configured to publish CloudStack events to RabbitMQ server. Documentation relating to Event Notification can found in - http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/A dmin_Guide/events.html#event-framework -Thanks Sangeetha Right, got all that. What I don't see is any implementation for how to consume the events in another region's management server. Perhaps that's work outstanding? -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, July 12, 2013 12:49 PM To: dev@cloudstack.apache.org Subject: Instructions to *consume* events in another region? Hi all, I've been slowly getting an environment up that can help me play with the regions feature. Do we have *any* docs out there (that I apparently can't find) that talk about how to get the mgmt servers to actually subscribe to changes that others are making? -chip
RE: Regions in 4.1
There is no UI support for regions in 4.1. All API calls relating to regions feature is implemented. Note that cloudstack does not do data sync between regions. There are few open issues relating to Regions and Event notifications: CLOUDSTACK-1673 - AWS Regions - Events - User disable / Domain Delete event does not include the UUID of the user/domain that was disabled. CLOUDSTACK-1775 - Events related User/Domain/Account are not being generated expect for USER-DISABLE,DOMAIN-DELETE and ACCOUNT.DISABLE event. CLOUDSTACK-1819 - AWS Regions - Issues seen when trying to move a zone from 1 region to another. -Thanks Sangeetha -Original Message- From: Mathias Mullins [mailto:mathias.mull...@citrix.com] Sent: Tuesday, July 09, 2013 8:34 AM To: dev@cloudstack.apache.org Subject: Regions in 4.1 Did the regions model get fully implemented in 4.1? Is it usable and functional? Has anyone actually deployed it yet with the 4.1 release? Thanks, Matt
RE: event bus details
I had logged a similar bug where the UUID of the user that was disabled and the
UUID of the domain that was deleted is not included:
CLOUDSTACK-1673 - AWS Regions - Events - User disable / Domain Delete event
does not include the UUID of the user/domain that was disabled.
-Thanks
Sangeetha
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Monday, June 24, 2013 9:24 PM
To: dev@cloudstack.apache.org
Subject: Re: event bus details
Here's another, when deleting a VPC. I see the details of all of the things
it's doing (removing the router, networks, etc), but I can't tell which VPC was
being deleted. I feel like that '*' under ActionEvent should be telling me the
uuid, like that position does in the other events:
[x]
'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{status:Scheduled,event:VPC.DELETE,account:f668198a-bbdf-11e2-8bb5-52540014c04d,user:f66f14d8-bbdf-11e2-8bb5-52540014c04d}'
[x]
'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{id:b18e3e07-aed0-473a-aeb2-bfad00bfb236,old-state:Running,new-state:Stopping,resource:Network}'
[x]
'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{id:b18e3e07-aed0-473a-aeb2-bfad00bfb236,old-state:Stopping,new-state:Stopped,resource:Network}'
[x]
'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{id:b18e3e07-aed0-473a-aeb2-bfad00bfb236,old-state:Stopped,new-state:Expunging,resource:Network}'
[x]
'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{id:5dca4da7-d428-4f6f-a474-11eee55fdf3a,old-state:Ready,new-state:Destroy,resource:Volume}'
[x]
'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{id:5dca4da7-d428-4f6f-a474-11eee55fdf3a,old-state:Ready,new-state:Destroy,resource:Volume}'
[x]
'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{id:5dca4da7-d428-4f6f-a474-11eee55fdf3a,old-state:Destroy,new-state:Destroy,resource:Volume}'
[x]
'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{id:5dca4da7-d428-4f6f-a474-11eee55fdf3a,old-state:Destroy,new-state:Destroy,resource:Volume}'
...
On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen shadow...@gmail.com wrote:
Hi all,
I've been playing around with the new event bus, trying to see if
it could be useful, and I'm a bit confused about the output. If I
subscribe to all topics, and try to reboot a virtual machine, this is
all I see:
'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{status:Scheduled,event:VM.REBOOT,account:f66d4d60-bbdf-11e2-8bb5-52540014c04d,user:f66f14d8-bbdf-11e2-8bb5-52540014c04d}'
I see the account info, but nothing about which VM is being rebooted.
If I try to stop/start a VM, I likewise see no details in the
ActionEvent, about the subject being acted upon:
'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{status:Scheduled,event:VM.STOP,account:f66d4d60-bbdf-11e2-8bb5-52540014c04d,user:f66f14d8-bbdf-11e2-8bb5-52540014c04d}'
I do however see some details regarding a 'Network' resource, though
if I were to write something to parse this output I wouldn't
immediately know that it was related to a VM (note the 'id' here
actually matches the VM I'm stopping, but there's nothing in the event
to tell me it's a VM):
'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b-4e8b-8fb2-268ec32c':'{id:d287a0fa-6b3b-4e8b-8fb2-268ec32c,old-state:Running,new-state:Stopping,resource:Network}'
I'm just subscribing to #, so I assume I'm getting everything, but
I'm just having trouble making sense of the output.
RE: [ANNOUNCE] New committer: Sailaja Mada
Congratulations Sailaja!! -Original Message- From: Ahmad Emneina [mailto:aemne...@gmail.com] Sent: Thursday, May 23, 2013 2:25 PM To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] New committer: Sailaja Mada Woohooo, congrats Sailaja. On Thu, May 23, 2013 at 2:23 PM, Pranav Saxena pranav.sax...@citrix.comwrote: Congrats Sailaja !:) -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, May 24, 2013 2:51 AM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Sailaja Mada The Project Management Committee (PMC) for Apache CloudStack has asked Sailaja Mada to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Sailaja! -chip on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Venkata Swamy
Congratulations Swamy. -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Thursday, May 23, 2013 2:33 PM To: dev@cloudstack.apache.org; Venkata SwamyBabu Budumuru Subject: Re: [ANNOUNCE] New committer: Venkata Swamy Venkata, congrats! On 5/23/13 2:21 PM, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Venkata Swamy to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Venkata! -chip on behalf of the CloudStack PMC
RE: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?
Templates for IPV6 feature in 4.1 is different from the 4.2 templates. They are hosted here - http://cloudstack.apt-get.eu/systemvm/ as 4.1.0-experimental-ipv6-* . Also support was extended only for KVM and Xenserver. -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Tuesday, May 21, 2013 4:27 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492? I'm not sure how well tested they are, but they're already more or less compatible. The idea was floated to provide ipv6 preview with instructions to use the 4.2 template. On May 21, 2013 5:09 PM, John Burwell jburw...@basho.com wrote: Chiradeep, Is it possible to back port the 4.2 system VMs to 4.1? What would be involved in such an effort? Thanks, -John On May 21, 2013, at 7:07 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: The latest 4.2 systemvms do have ntp built in. The earlier comment about HVM is incorrect. It is PV (PVOPS, to be exact). With PVOPS Linux vms, there is no sync between domU and dom0. On 5/21/13 2:45 PM, Marcus Sorensen shadow...@gmail.com wrote: +1, it seems that it is no worse off then it ever has been, aside +from the caveat that newer features are beginning to rely on it. I do agree though that it could perhaps be rolled into the newer system vm, as an option for people to use at their own risk. Of course, if someone wants to patch it up and get testing going, I'm all for that as well. I just don't see holding things up. On Tue, May 21, 2013 at 3:33 PM, John Burwell jburw...@basho.com wrote: David, I am willing to do the work. However, as I understand the circumstances, a complete build process for the system VMs has not been released. If I am incorrect in my understanding, I will do the work necessary to fix the problem. Thanks, -John On May 21, 2013, at 5:29 PM, David Nalley da...@gnsa.us wrote: On Mon, May 20, 2013 at 4:15 PM, Chip Childers chip.child...@sungard.com wrote: All, As discussed on another thread [1], we identified a bug (CLOUDSTACK-2492) in the current 3.x system VMs, where the System VMs are not configured to sync their time with either the host HV or an NTP service. That bug affects the system VMs for all three primary HVs (KVM, Xen and vSphere). Patches have been committed addressing vSphere and KVM. It appears that a correction for Xen would require the re-build of a system VM image and a full round of regression testing that image. Given that the discussion thread has not resulted in a consensus on this issue, I unfortunately believe that the only path forward is to call for a formal VOTE. Please respond with one of the following: +1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492 +being resolved +0: don't care one way or the other -1: do *not* proceed with any further 4.1 release candidates until CLOUDSTACK-2492 has been fully resolved -chip [1] http://markmail.org/message/rw7vciq3r33biasb So it appalls me that this problem exists. If I understand correctly, from folks who commercially support derivatives of ACS. Lack of time synchronization has been a factor in major outages, but that's typically been between the hypervisors and management servers. Regardless we realize (or should) that time is important for so many reasons (encryption, logs, and scores of other reasons) But when the rubber meets the road - here are the two points that decide it for me. 1. This is not a new problem. It's bad, it shouldn't exist, but it does, and it has for some time it would seem. That suggests it's not catastrophic, and hasn't yet blocked folks from getting things done with CloudStack. 2. I see no one stepping up to do the work. I am not personally a fan of issuing what is the effective equivalent of an 'unfunded mandate'. The problem isn't just one of building a new SSVM - it's one of testing it, and repeating all of the validation that has already been done with the existing sysvm. Perhaps there is a middle ground (we have a default sysvm, but perhaps like we are doing with the IPv6-enabled sysvm we have a time-enabled sysvm available for folks. Regardless - you called a vote, so I'll reluctantly cast a +1 - I hate that we are seeing this problem, but with no one stepping up to do all of the work, I'm not quite ready to hold a release hostage waiting to find such a person. --David
RE: listAffinityGroups API parameters
Hi, listAffinityGroups API should support for account and domainId parameters . All regular users (other than admin users) can list only affinity group that belongs to them. But Admin users should be able to list affinity groups that belong to other accounts passed in account and domain Id parameters. Following 2 bugs have already been logged for this regards: CLOUDSTACK-2350 - Anti-Affinity - As admin user, when trying to update the affinity group for a Vm that is deployed by a regular user , he is presented with admin's affinity groups. **This issue tracks the following 2 api issues which is the root cause of the bug: Using listAffinityGroups() call , Admin is not able to list affinity groups of other accounts by passing account and domainid parameter. when admin calls listAffinityGroups() without account and domainid parameter, all affinity groups belonging to all users need to be returned. CLOUDSTACK-2352 - Anti-Affinity - As admin user , not able to list affinity group created by other users by passing id parameter to listaffinitygroups command. . -Thanks Sangeetha -Original Message- From: Devdeep Singh [mailto:devdeep.si...@citrix.com] Sent: Friday, May 17, 2013 1:03 AM To: dev@cloudstack.apache.org Subject: RE: listAffinityGroups API parameters Looking at the code listAffinityGroup api doesn't take account name or domain id as a parameter. You may file a bug for this. Either the FS needs to be updated or the api needs to be updated for honoring these parameters. Regards, Devdeep -Original Message- From: Girish Shilamkar [mailto:gir...@clogeny.com] Sent: Friday, May 17, 2013 12:53 PM To: dev@cloudstack.apache.org Subject: listAffinityGroups API parameters Hello, While writing automation tests for listAffinityGroups API I found that the specs (http://tinyurl.com/agedzm2) specify account and domainid as parameters. But in marvin cloudstackAPI/listAffinityGroups.py it does not expect these parameters. I tried to list Affinity Groups through UI and it lists user's Affinity groups by listing vms only and not directly. Could someone please confirm ? Regards, Girish
RE: IPv6 support
Hi, IPV6 feature is supported in 4.1 but it is experimental and UI is not available. Also you will need to use System Vm templates that have support for ipv6. Only Phase 1 from the FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+support is supported. In 4.2 , there will be new System Vm templates that are made available that will have support for ipv6. Also UI will have support of IPV6 feature. -Thanks Sangeetha -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Wednesday, May 15, 2013 10:01 AM To: dev@cloudstack.apache.org Subject: IPv6 support Hi, Should I expect to have working IPv6 (for the VMs) in 4.1 or 4.2? If not, in which version is this feature expected to land? Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: Review request for Test Plan for Deploy virtual machine user data enhancements
Shweta, I have 1 suggestion after going over the test plans. As part of validations for your test cases could you also include the check to make sure that we are able to fetch the user data successfully from within the user Vms. Thanks Sangeetha -Original Message- From: Shweta Agarwal [mailto:shweta.agar...@citrix.com] Sent: Wednesday, May 08, 2013 3:35 AM To: dev@cloudstack.apache.org Subject: Review request for Test Plan for Deploy virtual machine user data enhancements I am taking up test execution for the feature : Deploy virtual machine user data enhancements I've written some test cases for the same. Please review and let me know if any comments. Here are Test cases: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+cases+for+DeployVirtualMachine+userdata+enhancements Ref FS for the feature is here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeployVirtualMachine+userdata+enhancements Thanks Shweta
Review Request: CLOUDSTACK-1820 - Automation: Need to add automation for AWS Style region feature
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10936/ --- Review request for cloudstack, Prasanna Santhanam and Girish Shilamkar. Description --- Added Test cases to test APIs relating to Regions feature. This addresses bug CLOUDSTACK-1820. Diffs - test/integration/component/test_regions.py PRE-CREATION tools/marvin/marvin/integration/lib/base.py bebf2b5 Diff: https://reviews.apache.org/r/10936/diff/ Testing --- Yes , master Thanks, sangeetha hariharan
Review Request: fix test scripts to conform with library changes relating to account object
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10941/ --- Review request for cloudstack, Prasanna Santhanam and Girish Shilamkar. Description --- Modify account.account.* to account.* This addresses bug 2329. Diffs - test/integration/component/test_regions.py PRE-CREATION Diff: https://reviews.apache.org/r/10941/diff/ Testing --- Able to execute test_regions.py . Earlier there were syntax errors. Thanks, sangeetha hariharan
Re: Review Request: fix regions related test script to conform with library changes relating to account object
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10941/ --- (Updated May 4, 2013, 1:29 a.m.) Review request for cloudstack, Prasanna Santhanam and Girish Shilamkar. Summary (updated) - fix regions related test script to conform with library changes relating to account object Description --- Modify account.account.* to account.* This addresses bug 2329. Diffs - test/integration/component/test_regions.py PRE-CREATION Diff: https://reviews.apache.org/r/10941/diff/ Testing --- Able to execute test_regions.py . Earlier there were syntax errors. Thanks, sangeetha hariharan
Re: Review Request: CLOUDSTACK-1820 - Automation: Need to add automation for AWS Style region feature
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10936/ --- (Updated May 4, 2013, 4:13 a.m.) Review request for cloudstack, Prasanna Santhanam and Girish Shilamkar. Description --- Added Test cases to test APIs relating to Regions feature. This addresses bug CLOUDSTACK-1820. Diffs - test/integration/component/test_regions.py PRE-CREATION tools/marvin/marvin/integration/lib/base.py bebf2b5 Diff: https://reviews.apache.org/r/10936/diff/ Testing (updated) --- Executed the scripts against a CloudStack set up and made sure they executed successfully. Thanks, sangeetha hariharan
RE: ssvm service name (vmware)
Sorry ..It is cloud . It is cloudstack-agent only for KVM hosts. -Thanks Sangeetha -Original Message- From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] Sent: Saturday, April 20, 2013 4:07 PM To: dev@cloudstack.apache.org Subject: RE: ssvm service name (vmware) It would be cloudstack-agent. Thanks Sangeetha Sent from my Windows Phone From: Fang Wangmailto:fang.w...@citrix.com Sent: 20-04-2013 02:28 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: ssvm service name (vmware) Hi, I'd like to stop and restart the SSVM. I login to ssvm and tried service cloud-agent restart On SSVM, but it did not find any cloud-agent service. Is the service name cloud instead of cloud-agent? This is on 4.1 branch , and hypervisor is Vmware, Thanks, -Fang
RE: [ACS42][QA]Issues with latest Master Build (Xenserver)
Thanks Prasanna. It was indeed the problem with my service offerings - I had memory requirement set to 124.00 MB not below 64 MB. When I increased it to 200 MB , I don't see the problem anymore. I have always used a service offering with 124.00 MB before on Xenserver 6.0.2 and did not encounter this issue before. -Thanks Sangeetha -Original Message- From: prasanna [mailto:srivatsav.prasa...@gmail.com] On Behalf Of Prasanna Santhanam Sent: Tuesday, April 16, 2013 11:58 PM To: dev@cloudstack.apache.org Subject: Re: [ACS42][QA]Issues with latest Master Build (Xenserver) On Tue, Apr 16, 2013 at 04:33:40PM -0700, Sangeetha Hariharan wrote: I am not able to start user Vms successfully using the build from master. I am testing with Xenserver 6.0.2 hosts. User Vm starts successfully but it gets to stopped state after few seconds. deployVM reports success . But later on cluster sync sees this Vm in stopped state and sends a StopCommand for this VM. It's not clustersync from the logs really. Something is going wrong on your xenserver. I've seen this happen when the VM deployed has mem limits outside the static-max and static-min defined by xenserver. So anything below 64MB memory starts and then stops. Not sure if that's the case with your deployed VM. -- Prasanna.,
RE: [QA][ACS42] Test Plan for Change Account Membership CS-1390
Parth, As part of verification after the change in ownership is done , can you include the following checks: 1. New owner is able to start the Vm successfully. 2. Original owner is not able to list this Vm. 3. Vm is not part of the original isolated network anymore and cannot be accessed from other Vms in this network. 3. Vm is part of a new isolated network that belongs to the new owner and that it can be accessed from other Vms in this network. -Thanks Sangeetha -Original Message- From: Parth Jagirdar [mailto:parth.jagir...@citrix.com] Sent: Monday, April 15, 2013 10:18 PM To: dev@cloudstack.apache.org Cc: Likitha Shetty Subject: [QA][ACS42] Test Plan for Change Account Membership CS-1390 All, Test Plan @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Change+account+membership+Test+Plan CS Bug @ https://issues.apache.org/jira/browse/CLOUDSTACK-1390 Requirements @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Change+account+membership FS UseCases @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Change+Account+Membership+-+VM ...Parth
RE: [ACS42][QA]Issues with latest Master Build (Xenserver)
When I deploy a Vm with service offering that has memory requirement set to 200.00 MB , Vm is in Running state but it actually has kernel panic. I am able to deploy Vms successfully only using Small Instance service offering that has 512MB memory requirement. Wanted to know why we are not able to deploy Vms with lesser RAM ? Is anybody else facing this issue? -Thanks Sangeetha From: Sangeetha Hariharan Sent: Wednesday, April 17, 2013 9:59 AM To: dev@cloudstack.apache.org Subject: RE: [ACS42][QA]Issues with latest Master Build (Xenserver) Thanks Prasanna. It was indeed the problem with my service offerings - I had memory requirement set to 124.00 MB not below 64 MB. When I increased it to 200 MB , I don’t see the problem anymore. I have always used a service offering with 124.00 MB before on Xenserver 6.0.2 and did not encounter this issue before. -Thanks Sangeetha -Original Message- From: prasanna [mailto:srivatsav.prasa...@gmail.com] On Behalf Of Prasanna Santhanam Sent: Tuesday, April 16, 2013 11:58 PM To: dev@cloudstack.apache.org Subject: Re: [ACS42][QA]Issues with latest Master Build (Xenserver) On Tue, Apr 16, 2013 at 04:33:40PM -0700, Sangeetha Hariharan wrote: I am not able to start user Vms successfully using the build from master. I am testing with Xenserver 6.0.2 hosts. User Vm starts successfully but it gets to stopped state after few seconds. deployVM reports success . But later on cluster sync sees this Vm in stopped state and sends a StopCommand for this VM. It's not clustersync from the logs really. Something is going wrong on your xenserver. I've seen this happen when the VM deployed has mem limits outside the static-max and static-min defined by xenserver. So anything below 64MB memory starts and then stops. Not sure if that's the case with your deployed VM. -- Prasanna.,
RE: How to set the default network when I specify IP use iptonetworklist parameter when deploy a vm?
We did have an issue where default network was not programmed correctly in 4.1 which is now fixed: CLOUDSTACK-1115 - In multiple shared network unable to login with default nic - KVM It is possible you are hitting the same issue , not sure. Both iptonetworklist and networkIds cannot be used in deployVirtualMachine() . This is by design. When using iptonetworklist parameter , iptonetworklist[0].networkid should be used as default network. -Thanks Sangeetha -Original Message- From: sx chen [mailto:cloudchen0...@gmail.com] Sent: Monday, April 15, 2013 7:28 PM To: us...@cloudstack.apache.org; dev@cloudstack.apache.org Subject: Re: How to set the default network when I specify IP use iptonetworklist parameter when deploy a vm? Thanks,Alena and Sangeetha My environment is CS 3.02,I want make the default nic is 10.10.4.41,I've made these test: 1. iptonetworklist[0].ip=10.10.4.41iptonetworklist[0].networkid=233iptonetworklist[1].ip=10.10.15.91iptonetworklist[1].networkid=234iptonetworklist[2].ip=10.10.16.91iptonetworklist[2].networkid=235 the default nic is 10.10.16.91 2. iptonetworklist[0].ip=10.10.16.91iptonetworklist[0].networkid=235iptonetworklist[1].ip=10.10.15.91iptonetworklist[1].networkid=234iptonetworklist[2].ip=10.10.4.41iptonetworklist[2].networkid=233 the default nic is 10.10.16.91 3. iptonetworklist[0].ip=10.10.4.41iptonetworklist[0].networkid=233iptonetworklist[1].ip=10.10.15.91iptonetworklist[1].networkid=234iptonetworklist[2].ip=10.10.16.91iptonetworklist[2].networkid=235networkids=233 response:ipToNetworkMap can't be specified along with networkIds or ipAddress So,It seems the iptonetworklist can't use with networkIds. also I can't specify the default network by set it in iptonetworklist[0]. maybe a commit after 3.02 has solve this problem? 2013/4/16 Sangeetha Hariharan sangeetha.hariha...@citrix.com When using iptonetworklist when deploying Vms ,first entry in the iptonetworklist ( iptonetworklist[0].networkid) becomes the default network. -Thanks Sangeetha -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Monday, April 15, 2013 9:32 AM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Re: How to set the default network when I specify IP use iptonetworklist parameter when deploy a vm? NetworkIds parameter has to be specify regardless of iptonetworklist parameter presence. So you have to define both parameters, and the first network from the networkIds list will be used as a default. -Alena. On 4/15/13 7:44 AM, sx chen cloudchen0...@gmail.com wrote: Hi, as far as I know, I can specify the default network by put it at the first when use *networkids* paramenter when deploy a vm. but if I use iptonetworklist parameter specify the IP address,I find I can't specify the default network.I've test put it at the first and put it at the last. So if I want to specify the default network as well as the IP address,what should I do? appreciate your help！
RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
I still see this issue on master build , where after executing cloudstack-setup-databases DB version is still pointing to 4.0.0. I have logged the following bug to track this issue: CLOUDSTACK-2052 - After executing cloudstack-setup-databases , DB version is still pointing to 4.0.0. -Thanks Sangeetha -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Thursday, March 21, 2013 11:56 AM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Wednesday, March 20, 2013 11:27 PM To: cloudstack-...@incubator.apache.org Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry- pick commits from master On Thu, Mar 21, 2013 at 1:54 AM, Alex Huang alex.hu...@citrix.com wrote: Hi everyone, We had a discussion on irc. To implement something intermediary will be around the same effort as finishing the job and there are various reasons why just running the create- schema.sql and update*.sql is not enough. So we should just decide on finishing the job in 4.1 or document the behavior. Any input on which way we should take. The engineer in me says just finish the job. It's obviously working in dev setup on master so the risk of this introducing bugs is very low. If someone knows why it's difficult to change in cloud-setup-databases script, please speak up. Alex asks why it is difficult to change in cloud-setup-database script? Rohit, Actually, I really just meant was there technical challenges in updating the script that was already looked into. Sounds like from your reply there isn't. Appreciate your work on the various parts. It was excellent. Good luck on your next venture. --Alex
RE: [ACS42][QA]Issues with latest Master Build (Xenserver)
I am not able to start user Vms successfully using the build from master. I am
testing with Xenserver 6.0.2 hosts.
User Vm starts successfully but it gets to stopped state after few seconds.
deployVM reports success . But later on cluster sync sees this Vm in stopped
state and sends a StopCommand for this VM.
Is anyone seeing this issue?
Management server logs:
2013-04-16 16:21:13,805 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-21:null) 2. The VM i-2-10-VM is in Running state.
2013-04-16 16:21:13,806 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-21:null) Seq 5-1032650792: Response Received:
2013-04-16 16:21:13,806 DEBUG [agent.transport.Request] (DirectAgent-21:null)
Seq 5-1032650792: Processing: { Ans: , MgmtId: 7508777239729, via: 5, Ver: v1,
Flags: 110, [
{StartAnswer:{vm:{id:10,name:i-2-10-VM,bootloader:PyGrub,type:User,cpus:1,minSpeed:100,maxSpeed:100,minRam:130023424,maxRam:130023424,arch:x
86_64,os:CentOS 5.3
(64-bit),bootArgs:,rebootOnCrash:false,enableHA:false,limitCpuUse:false,vncPassword:10394489c81710b9,params:{},uuid:c0c0ee3a-af
91-4595-a1a3-4c3317489a03,disks:[{id:10,name:ROOT-10,mountPoint:/export/home/sangeetha/asf42-2/primary2,path:eeeccffd-a86d-44ec-89f0-0e7923712ac2,size:8
589934592,type:ROOT,storagePoolType:NetworkFilesystem,storagePoolUuid:f483cba6-d7e9-38ad-ad5f-4c4971a2b06f,deviceId:0},{id:10,name:test-123,size:0,t
ype:ISO,storagePoolType:ISO,deviceId:3}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,uuid:c726c8bf-3d17-4d9b-bae1-3e885461e4ab,ip:10.1.1.
224,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:1a:b3:00:06,dns1:72.52.126.11,dns2:72.52.126.12,broadcastType:Vlan,type:Guest,broadcastU
ri:vlan://2090,isolationUri:vlan://2090,isSecurityGroupEnabled:false}]},result:true,wait:0}}]
}
2013-04-16 16:21:13,806 DEBUG [agent.transport.Request] (Job-Executor-3:job-39)
Seq 5-1032650792: Received: { Ans: , MgmtId: 7508777239729, via: 5, Ver: v1,
Flags: 110, {
StartAnswer } }
2013-04-16 16:21:13,808 DEBUG [agent.manager.AgentAttache]
(DirectAgent-21:null) Seq 5-1032650792: No more commands found
2013-04-16 16:21:13,838 DEBUG [cloud.network.NetworkModelImpl]
(Job-Executor-3:job-39) Service SecurityGroup is not supported in the network
id=205
2013-04-16 16:21:13,841 DEBUG [cloud.network.NetworkModelImpl]
(Job-Executor-3:job-39) Service SecurityGroup is not supported in the network
id=205
2013-04-16 16:21:13,846 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-3:job-39) VM state transitted from :Starting to Running with
event: OperationSucceededvm's
original host id: 5 new host id: 5 host id before state transition: 5
2013-04-16 16:21:13,846 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-3:job-39) Start completed for VM VM[User|again]
2013-04-16 16:22:04,873 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-14:null) Ping from 4
2013-04-16 16:22:08,511 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-60:null) Ping from 5
2013-04-16 16:22:08,637 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-61:null) Ping from 1
2013-04-16 16:22:09,046 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-9:null) Seq 5-1032650756: Executing request
2013-04-16 16:22:09,289 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-9:null) The VM is now missing marking it as Stopped i-2-10-VM
2013-04-16 16:22:09,290 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-9:null) Seq 5-1032650756: Response Received:
2013-04-16 16:22:09,290 DEBUG [agent.transport.Request] (DirectAgent-9:null)
Seq 5-1032650756: Processing: { Ans: , MgmtId: 7508777239729, via: 5, Ver: v1,
Flags: 10,
[{ClusterSyncAnswer:{_clusterId:2,_newStates:{i-2-10-VM:{t:b8f8a7e3-a6af-499f-9168-94691ca06b20,u:Stopped}},_isExecuted:false,result:true,wait:0}}]
}
2013-04-16 16:22:09,294 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(DirectAgent-9:null) VM i-2-10-VM: cs state = Running and realState = Stopped
2013-04-16 16:22:09,294 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(DirectAgent-9:null) VM i-2-10-VM: cs state = Running and realState = Stopped
2013-04-16 16:22:09,294 DEBUG [cloud.ha.HighAvailabilityManagerImpl]
(DirectAgent-9:null) VM does not require investigation so I'm marking it as
Stopped: VM[User|again]
2013-04-16 16:22:09,294 WARN [apache.cloudstack.alerts] (DirectAgent-9:null)
alertType:: 8 // dataCenterId:: 1 // podId:: 2 // clusterId:: null // message::
VM (name: again, id: 10) stopped unexpectedly on host id:5, availability zone
id:1, pod id:2
2013-04-16 16:22:09,301 DEBUG [cloud.ha.HighAvailabilityManagerImpl]
(DirectAgent-9:null) VM is not HA enabled so we're done.
2013-04-16 16:22:09,308 DEBUG [cloud.capacity.CapacityManagerImpl]
(DirectAgent-9:null) VM state transitted from :Running to Stopping with event:
StopRequestedvm's original host id: 5 new host id: 5 host id before state
transition: 5
2013-04-16 16:22:09,310 DEBUG [agent.transport.Request] (DirectAgent-9:null)
Seq 5-1032650795: Sending { Cmd , MgmtId:
RE: How to set the default network when I specify IP use iptonetworklist parameter when deploy a vm?
When using iptonetworklist when deploying Vms ,first entry in the iptonetworklist ( iptonetworklist[0].networkid) becomes the default network. -Thanks Sangeetha -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Monday, April 15, 2013 9:32 AM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Re: How to set the default network when I specify IP use iptonetworklist parameter when deploy a vm? NetworkIds parameter has to be specify regardless of iptonetworklist parameter presence. So you have to define both parameters, and the first network from the networkIds list will be used as a default. -Alena. On 4/15/13 7:44 AM, sx chen cloudchen0...@gmail.com wrote: Hi, as far as I know, I can specify the default network by put it at the first when use *networkids* paramenter when deploy a vm. but if I use iptonetworklist parameter specify the IP address,I find I can't specify the default network.I've test put it at the first and put it at the last. So if I want to specify the default network as well as the IP address,what should I do? appreciate your help！
RE: The given command does not exist or it is not available for user
I have seen this issue happen intermittently when the management server has not yet loaded all the components but we are able to access the management server UI. At this point , when we log in , we are presented with The given command does not exist or it is not available for user. But when you try to log in after few minutes (after the components loading is completed) , you will be able to log in successfully. Is this the kind of issues you are facing? 2013-04-12 11:46:53,228 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.network.guru.OvsGuestNetworkGuru_EnhancerByCloudStack_d7cda260 2013-04-12 11:46:53,228 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.hypervisor.guru.VMwareGuru_EnhancerByCloudStack_4fd95e3d 2013-04-12 11:46:53,228 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.network.guru.StorageNetworkGuru_EnhancerByCloudStack_42e7a777 2013-04-12 11:46:53,228 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.network.element.MidoNetElement_EnhancerByCloudStack_c15799f2 2013-04-12 11:46:53,230 INFO [network.element.MidoNetElement] (Timer-1:null) midonet API server address is http://localhost:8081 2013-04-12 11:46:53,399 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null) ===START=== 10.217.252.128 -- POST null 2013-04-12 11:46:53,419 DEBUG [cloud.user.AccountManagerImpl] (catalina-exec-19:null) Attempting to log in user: admin in domain 1 2013-04-12 11:46:53,419 DEBUG [server.auth.SHA256SaltedUserAuthenticator] (catalina-exec-19:null) Retrieving user: admin 2013-04-12 11:46:54,360 DEBUG [cloud.user.AccountManagerImpl] (catalina-exec-19:null) User: admin in domain 1 has successfully logged in 2013-04-12 11:46:54,410 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null) ===END=== 10.217.252.128 -- POST null 2013-04-12 11:46:54,451 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) ===START=== 10.217.252.128 -- GET command=listCapabilitiesresponse=jsonsessionkey=Bqhd5Xu2xRt2Zy5pmcwSKJBNLrg%3D_=1365792760278 2013-04-12 11:46:54,469 DEBUG [cloud.api.ApiServer] (catalina-exec-24:null) The given command:listCapabilities does not exist or it is not available for user with id:2 2013-04-12 11:46:54,497 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) ===END=== 10.217.252.128 -- GET command=listCapabilitiesresponse=jsonsessionkey=Bqhd5Xu2xRt2Zy5pmcwSKJBNLrg%3D_=1365792760278 2013-04-12 11:46:54,521 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===START=== 10.217.252.128 -- GET command=listSwiftsresponse=jsonsessionkey=Bqhd5Xu2xRt2Zy5pmcwSKJBNLrg%3D_=1365792760350 2013-04-12 11:46:54,530 DEBUG [cloud.api.ApiServer] (catalina-exec-5:null) The given command:listSwifts does not exist or it is not available for user with id:2 2013-04-12 11:46:54,533 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===END=== 10.217.252.128 -- GET command=listSwiftsresponse=jsonsessionkey=Bqhd5Xu2xRt2Zy5pmcwSKJBNLrg%3D_=1365792760350 2013-04-12 11:46:56,328 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring org.apache.cloudstack.storage.allocator.ClusterScopeStoragePoolAllocator_EnhancerByCloudStack_580b2575 2013-04-12 11:46:56,333 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring org.apache.cloudstack.storage.allocator.GarbageCollectingStoragePoolAllocator_EnhancerByCloudStack_f46bb5fa 2013-04-12 11:46:56,363 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring org.apache.cloudstack.acl.StaticRoleBasedAPIAccessChecker_EnhancerByCloudStack_cbfe3f69 2013-04-12 11:46:56,378 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.ha.KVMFencer_EnhancerByCloudStack_afa1b038 2013-04-12 11:46:56,378 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.network.element.VirtualRouterElement_EnhancerByCloudStack_5301d244 2013-04-12 11:46:56,378 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.ha.XenServerFencer_EnhancerByCloudStack_75828daa 2013-04-12 11:46:56,378 INFO [utils.component.ComponentContext] (Timer-1:null) Configuring com.cloud.storage.secondary.SecondaryStorageVmDefaultAllocator_EnhancerByCloudStack_b44dce17 Thanks Sangeetha -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Friday, April 12, 2013 10:51 AM To: dev@cloudstack.apache.org Subject: Re: The given command does not exist or it is not available for user Probably an ACL issue, occurs when a user is trying to execute an API they are not allowed; or the API does not exist. HTH. On Apr 12, 2013 7:28 PM, Paul Angus paul.an...@shapeblue.com wrote: Hi All, When I try to log in to the current build of CloudStack 4.1 I get an error in the browser: The given command does not exist or it is not available for user The management-server.log shows: 2013-04-12 13:52:55,796 DEBUG
RE: CLOUDSTACK-1732
Thank you Marcus. Test with the latest build from master. When deploying a Vm on a IP6 network , we see the dnsmasq service running successfully in the router . Vms get deployed successfully and get an Ipv6 address. I have closed the bug. -Thanks Sangeetha -Original Message- From: Sheng Yang [mailto:sh...@yasker.org] Sent: Wednesday, April 10, 2013 3:08 PM To: Marcus Sorensen Cc: dev@cloudstack.apache.org Subject: Re: CLOUDSTACK-1732 Thanks! We can continue the testing now. :) --Sheng On Wed, Apr 10, 2013 at 12:28 PM, Marcus Sorensen shadow...@gmail.comwrote: commit f66b9b570f2acb35acfda2d159dcde6fa62390d5 Author: Marcus Sorensen mar...@betterservers.com Date: Wed Apr 10 13:27:10 2013 -0600 Send only \n rather than \r\n to agent socket when sending cmdline to system VMS BUG-ID: CLOUDSTACK-1732 Signed-off-by: Marcus Sorensen mar...@betterservers.com 1365622030 -0600 On Wed, Apr 10, 2013 at 1:18 PM, Marcus Sorensen shadow...@gmail.comwrote: yes, you're right, I just ran into this today. The \r\n I believed was necessary for the socket to flush, but apparently it isn't. If the patch is in a request you can apply it. On Wed, Apr 10, 2013 at 12:44 PM, Sheng Yang sh...@yasker.org wrote: Hi Marcus, I found this 4.2 blocker bug https://issues.apache.org/jira/browse/CLOUDSTACK-1732 caused by your commit to change the communication mechanism for KVM systemvm. As I said, I am not very familiar with python, but seems \r\n would generated ^M rather than normal unix return character. I've tried following fix and it works. But I am not sure if it's the right fix, because obviously \r\n is more complex than \n, so you should had reason to do so. yasker@yasker-devbox:~/develop/cloudstack-oss$ git diff diff --git a/scripts/vm/hypervisor/kvm/patchviasocket.plb/scripts/vm/hypervisor /kvm/ patchviasocket.pl index 443d6e4..7bcd245 100644 --- a/scripts/vm/hypervisor/kvm/patchviasocket.pl +++ b/scripts/vm/hypervisor/kvm/patchviasocket.pl @@ -53,6 +53,6 @@ my $msg = pubkey: . $key . \ncmdline: . $cmdline; my $socket = IO::Socket::UNIX-new(Peer=$sockfile,Type=SOCK_STREAM) or die ERROR: unable to connect to $sockfile - $^E\n; -print $socket $msg\r\n; +print $socket $msg\n; close $socket; So could you shed some lights on it? Thanks! --Sheng
RE: [DIscuss]Storage image store plugin framework refactoring
Can image stores from different providers (NFS,SWIFT,S3) coexist in the same deployment ? Is the scope for NFS always Zone-wide and SWIFT and S3 region-wide? There is an api for enableImageStoreCmd . Can multiple image stores be enabled at the same time? I don't see any api for disabling image store? What does it mean to disable an already enabled image store? Will all the resources like templates, iso and snapshot residing in this image store not be available to the users anymore? deleteImageStoreCmd - Will we allow for deletion of an image store when it has resources like templates, iso and snapshots residing in it? -Thanks Sangeetha -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Tuesday, April 09, 2013 2:01 PM To: dev@cloudstack.apache.org Subject: RE: [DIscuss]Storage image store plugin framework refactoring -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, April 08, 2013 11:33 PM To: dev@cloudstack.apache.org Subject: Re: [DIscuss]Storage image store plugin framework refactoring We can't deprecate APIs unless we are changing to 5.0 AFAIK the next release in plan is 4.2 For back compatibility, these APIs: addSecondaryStorageCmd,addS3Cmd,addSwiftCmd,listS3Cmd,listSwiftCmd, can still be wired to new code, so this APIs will still work, but we can mark them as deprecated in the API document. How does an upgrade from 4.0/4.1 to 4.2 work with this proposal? - what happens to existing SSVMs? - if there are multiple SSVMs? - current cache-like deployments for S3 and Swift The existing deployment model will still work. There are following combinations currently supported by CloudStack: 1. Only NFS as secondary storage. In the new framework, it's NFS as a backup storage. 2. NFS + swift/S3. In the new framework, it's swift/s3 as backup storage, while, NFS as cache storage. So the upgrade code from pre-4.2 to 4.2 needs to handle above cases, migrate DB properly. The SSVM code also does duty for VMWare deployments to aid in data movement. The existing SSVM will still work, it will be renamed to transportation VM in the code(maybe on the UI, it still be called SSVM). The main functionality of these VMs are to help transfer data from one place to another. As you said, Vmware deployment needs these VMs(as Vmware can't directly download template into primary storage), and old NFS based secondary storage deployment model needs them(data copy when cross zone). How does this change? On 4/8/13 6:34 PM, Sangeetha Hariharan sangeetha.hariha...@citrix.com wrote: Min, Could you also include the details of the API changes (new parameters) that will be proposed as part of this feature? Also it would be helpful if you list the request and response parameters for the new API calls. For all the API calls that are being deprecated , is there any specific error message that will be returned? -Thanks Sangeetha -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Monday, April 08, 2013 4:45 PM To: dev@cloudstack.apache.org Subject: [DIscuss]Storage image store plugin framework refactoring Hi All, Currently CloudStack does not offer a flexible pluggable framework for users to easily integrate and configure any 3rd-party object stores for such backup services as registering templates, taking snapshots, etc. Along with Edison's recent refactored storage subsystem 2.0 that mainly refactored current CloudStack primary storage implementation, we are proposing to develop a storage backup object store plugin framework to allow CloudStack to systematically manage and configure various types of backup data stores from different vendors, like NFS, S3, Swift, etc. With this new plugin framework, we would like to achieve following functionalities: 1. Support different object store providers in a uniform and pluggable fashion. 2. Enable region wide object backup using S3-like object store. 3. Provide pluggable data motion strategies to handle data transfer from one data store to another data store. 4. Provide a scalable cache storage framework while moving data between primary storage and backup storage for certain hypervisor needs. 5. Support flexible combinations of primary storage, secondary storage and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware), (ISCSI, Swift, KVM), , etc. The proposed ImageStore plugin framework architecture is detailed in our FS here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backu p+O bje ct+Store+Plugin+Framework. The JIRA ticket to track this feature is: https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is currently carried out in feature branch object_store. Please let me know your comments and suggestions. Thanks -min
RE: [ACS42][QA]Test Plan for Affinity / Anti-affinity Rules
Thank you for the review comments Prachi. For the test cases relating to UpdateVMAffinityGroup() , I will add the testcases where the Vm cannot be started on the last host on which it was running before being stopped. For live migration test case , I will update the expected result as per the review comments. -Thanks Sangeetha -Original Message- From: Prachi Damle [mailto:prachi.da...@citrix.com] Sent: Monday, April 08, 2013 1:57 PM To: dev@cloudstack.apache.org Subject: RE: [ACS42][QA]Test Plan for Affinity / Anti-affinity Rules Hi Sangeetha, The test plan looks fine. A few comments 1) UpdateVMAffinityGroup API - We should add to the testcases, the scenario where an already existing VM say on host1, is updated to have affinity group A1 that asks to avoid host1. In this case, the VM cannot restart on host1, but should start on some other host within or outside cluster. 2) And #66 Live migration - Live migration of Vms which are associated with anti-affinity group failing - The live migration will still succeed since it is Admin's choice to use host2 even if it is not suitable. We just indicate if the host is suitable or not, but CS should not stop Admin from live migrating. Prasanna, Affinity Group Processing is a pre-planning step. It will set the scope for the deployment planners, there is no conflict between the planner strategies and affinity groups. These are separate steps of deployment planning. Thanks, Prachi -Original Message- From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] On Behalf Of prasanna Sent: Friday, April 05, 2013 6:24 AM To: dev@cloudstack.apache.org Subject: Re: [ACS42][QA]Test Plan for Affinity / Anti-affinity Rules On 4 April 2013 10:40, Sangeetha Hariharan sangeetha.hariha...@citrix.com wrote: Test cases for Affinity / Anti-affinity Rules is posted here - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Paln+for+Affinity-Anti-affinity+Rules. Reference FS: - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-A nti-affinity+groups There are planning decisions that are controlled in the global settings that do similar things as do affinity groups. UserConcentration and UserDispersion are two kinds of allocators that affect planning decision very similar to affinity and anti-affinity. Some cases surrounding the conflicts arising from these settings would need to be added. Rest of the tests look good given that the scope of the feature is only a single anti-affinity processor at this time.
RE: [ACS42][QA]Test Plan for Affinity / Anti-affinity Rules
1 follow up question : 2) And #66 Live migration - Live migration of Vms which are associated with anti-affinity group failing - The live migration will still succeed since it is Admin's choice to use host2 even if it is not suitable. We just indicate if the host is suitable or not, but CS should not stop Admin from live migrating. Vm migration in such cases will succeed. But when Vms are stopped and started , it will fail to start since the anti-affinity group check will fail ? -Thanks Sangeetha Thanks Sangeetha -Original Message- From: Prachi Damle [mailto:prachi.da...@citrix.com] Sent: Monday, April 08, 2013 1:57 PM To: dev@cloudstack.apache.org Subject: RE: [ACS42][QA]Test Plan for Affinity / Anti-affinity Rules Hi Sangeetha, The test plan looks fine. A few comments 1) UpdateVMAffinityGroup API - We should add to the testcases, the scenario where an already existing VM say on host1, is updated to have affinity group A1 that asks to avoid host1. In this case, the VM cannot restart on host1, but should start on some other host within or outside cluster. 2) And #66 Live migration - Live migration of Vms which are associated with anti-affinity group failing - The live migration will still succeed since it is Admin's choice to use host2 even if it is not suitable. We just indicate if the host is suitable or not, but CS should not stop Admin from live migrating. Prasanna, Affinity Group Processing is a pre-planning step. It will set the scope for the deployment planners, there is no conflict between the planner strategies and affinity groups. These are separate steps of deployment planning. Thanks, Prachi -Original Message- From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] On Behalf Of prasanna Sent: Friday, April 05, 2013 6:24 AM To: dev@cloudstack.apache.org Subject: Re: [ACS42][QA]Test Plan for Affinity / Anti-affinity Rules On 4 April 2013 10:40, Sangeetha Hariharan sangeetha.hariha...@citrix.com wrote: Test cases for Affinity / Anti-affinity Rules is posted here - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Paln+for+Affinity-Anti-affinity+Rules. Reference FS: - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-A nti-affinity+groups There are planning decisions that are controlled in the global settings that do similar things as do affinity groups. UserConcentration and UserDispersion are two kinds of allocators that affect planning decision very similar to affinity and anti-affinity. Some cases surrounding the conflicts arising from these settings would need to be added. Rest of the tests look good given that the scope of the feature is only a single anti-affinity processor at this time.
RE: [DISCUSS] Upgrade from 4.0 - 4.1 ( components.xml and db.propetries)
Yes awsapi is optional. But if someone wants to use the EC2 api query feature then there is a dependency that db.awsapi.* are set correctly. -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Tuesday, April 02, 2013 10:37 PM To: dev@cloudstack.apache.org Cc: cloudstack-...@incubator.apache.org Subject: Re: [DISCUSS] Upgrade from 4.0 - 4.1 ( components.xml and db.propetries) People aren't required to set up the awsapi, right? Many won't need it. Just wondering if it should be reflected as optional. For #2, we should tell them to add the lines to their db.properties, but also save the example db.properties. I've pushed a commit to save the example one for RPM installations, although it doesn't do much to solve the issue since the user still needs to either copy their existing config into it or modify their existing config adding the lines you mention. On Tue, Apr 2, 2013 at 8:23 PM, Sangeetha Hariharan sangeetha.hariha...@citrix.com wrote: Wanted to discuss about how to deal with components.xml and db.properties when upgrading from 4.0 -4.1. 1. If someone has made changes to your existing copy of the file components.xml in your previous-version CloudStack installation , after upgrade they will have to translate these changes into the current componentContext.xml file which is located in /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/componentContext.xml. This step needs to be documented in the upgrade procedure. Had a question here. Should we ideally maintain the location of the componentContext.xml to be the same as it was in 4.0? It is now present in a completely different location. 2. When we upgrade from 4.0 to 4.1 , we do not have a copy of db.properties that comes from a 4.1 installation saved anywhere. I have logged the following bug to track this issue: CLOUDSTACK-1900https://issues.apache.org/jira/browse/CLOUDSTACK-1900 - Upgrade 4.0 - 4.1 , We do not have a copy of db.properties that comes from a 4.1 installation saved anywhere. This needs to be saved , So that as part of upgrade instructions we can ask that the user makes his current db.properties compatible with this version. This step is documented as part of upgrade procedures from 2.2.14- 4.0 and 3.0.2-4.0. I see the following awsapi missing in db.properties when upgrading from 4.0 - 4.1: db.awsapi.username=cloud db.awsapi.password=cloud db.awsapi.host=localhost db.awsapi.port=3306 What should the solution for this issue be ? -Thanks Sangeetha
RE: [DISCUSS] Affinity / Anti-affinity Rules
Thanks Prachi. I had couple of more questions: ListAffinityGroups API() - When affinity group is returned would it return all the Vms associated with it in the affinity group as well ? Also listVm call should also include the list of affinity group it is associated with. -Thanks Sangeetha -Original Message- From: Prachi Damle [mailto:prachi.da...@citrix.com] Sent: Tuesday, April 02, 2013 11:27 AM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules Hi Sangeetha, Answered inline, Prachi -Original Message- From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] Sent: Tuesday, April 02, 2013 11:08 AM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules Prachi , Thanks for your response. Had 1 follow up question : 5.DeleteAffinityGroup API: Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group? Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ? [Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed. To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose. [Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup? By calling this API with a affinityGroup and VM , I thought we will associate this VM to the affinity group ? Is that correct? [Prachi] It is update the set of affinity groups of a VM. So this call will wipe out the existing group associations of the VM and create the new associations. If you do not include some existing affinity group in this API call, it will get removed. -Thanks Sangeetha -Original Message- From: Prachi Damle [mailto:prachi.da...@citrix.com] Sent: Monday, April 01, 2013 7:51 PM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules Comments inline. Thanks, Prachi -Original Message- From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] Sent: Monday, April 01, 2013 5:45 PM To: cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups : 1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required? 2.Can new DB changes introduced by this feature be included ? [Prachi] Will update FS with this info. 3.CreateAffinityGroup API: Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption? [Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only. 4.ListAffinityGroups API: Will admin/domain admin user be able to list the affinity groups of the other regular users ? [Prachi] No, same as above. 5.DeleteAffinityGroup API: Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group? Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ? [Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed. To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose. 6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ? [Prachi] Yes. 7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ? [Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed. 8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ? [Prachi] yes 9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ? [Prachi] Nope 10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs
RE: [DISCUSS] Upgrade from 4.0 - 4.1 ( components.xml and db.propetries)
As a follow up on the discussion we had on the IRC meeting , I have updated the existing doc bug relating to upgrade - CLOUDSTACK-1837 , to include the following 2 steps as well as part of upgrade: 1. If someone has made changes to your existing copy of the file components.xml in your previous-version CloudStack installation , after upgrade they will have to translate these changes into the current componentContext.xml file which is located in /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/componentContext.xml. 2. If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do keep your db.properties file compatible 4.1 version of db.properties. Following awsapi missing in db.properties when upgrading from 4.0 - 4.1: db.awsapi.username= db.awsapi.password= db.awsapi.host= db.awsapi.port= You have to add these entries to db.properties , if you want AWS query APIs to work. -Thanks Sangeetha -Original Message- From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] Sent: Wednesday, April 03, 2013 10:06 AM To: dev@cloudstack.apache.org Cc: cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Upgrade from 4.0 - 4.1 ( components.xml and db.propetries) Yes awsapi is optional. But if someone wants to use the EC2 api query feature then there is a dependency that db.awsapi.* are set correctly. -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Tuesday, April 02, 2013 10:37 PM To: dev@cloudstack.apache.org Cc: cloudstack-...@incubator.apache.org Subject: Re: [DISCUSS] Upgrade from 4.0 - 4.1 ( components.xml and db.propetries) People aren't required to set up the awsapi, right? Many won't need it. Just wondering if it should be reflected as optional. For #2, we should tell them to add the lines to their db.properties, but also save the example db.properties. I've pushed a commit to save the example one for RPM installations, although it doesn't do much to solve the issue since the user still needs to either copy their existing config into it or modify their existing config adding the lines you mention. On Tue, Apr 2, 2013 at 8:23 PM, Sangeetha Hariharan sangeetha.hariha...@citrix.com wrote: Wanted to discuss about how to deal with components.xml and db.properties when upgrading from 4.0 -4.1. 1. If someone has made changes to your existing copy of the file components.xml in your previous-version CloudStack installation , after upgrade they will have to translate these changes into the current componentContext.xml file which is located in /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/componentContext.xml. This step needs to be documented in the upgrade procedure. Had a question here. Should we ideally maintain the location of the componentContext.xml to be the same as it was in 4.0? It is now present in a completely different location. 2. When we upgrade from 4.0 to 4.1 , we do not have a copy of db.properties that comes from a 4.1 installation saved anywhere. I have logged the following bug to track this issue: CLOUDSTACK-1900https://issues.apache.org/jira/browse/CLOUDSTACK-1900 - Upgrade 4.0 - 4.1 , We do not have a copy of db.properties that comes from a 4.1 installation saved anywhere. This needs to be saved , So that as part of upgrade instructions we can ask that the user makes his current db.properties compatible with this version. This step is documented as part of upgrade procedures from 2.2.14- 4.0 and 3.0.2-4.0. I see the following awsapi missing in db.properties when upgrading from 4.0 - 4.1: db.awsapi.username=cloud db.awsapi.password=cloud db.awsapi.host=localhost db.awsapi.port=3306 What should the solution for this issue be ? -Thanks Sangeetha
[ACS42][QA]Test Plan for Affinity / Anti-affinity Rules
Test cases for Affinity / Anti-affinity Rules is posted here - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Paln+for+Affinity-Anti-affinity+Rules. Reference FS: - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups Please review and provide your feedback. Thanks, Sangeetha
RE: [DISCUSS] Affinity / Anti-affinity Rules
Prachi , Thanks for your response. Had 1 follow up question : 5.DeleteAffinityGroup API: Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group? Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ? [Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed. To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose. [Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup? By calling this API with a affinityGroup and VM , I thought we will associate this VM to the affinity group ? Is that correct? -Thanks Sangeetha -Original Message- From: Prachi Damle [mailto:prachi.da...@citrix.com] Sent: Monday, April 01, 2013 7:51 PM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules Comments inline. Thanks, Prachi -Original Message- From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] Sent: Monday, April 01, 2013 5:45 PM To: cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups : 1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required? 2.Can new DB changes introduced by this feature be included ? [Prachi] Will update FS with this info. 3.CreateAffinityGroup API: Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption? [Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only. 4.ListAffinityGroups API: Will admin/domain admin user be able to list the affinity groups of the other regular users ? [Prachi] No, same as above. 5.DeleteAffinityGroup API: Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group? Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ? [Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed. To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose. 6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ? [Prachi] Yes. 7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ? [Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed. 8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ? [Prachi] yes 9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ? [Prachi] Nope 10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions? [Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct, since the underlying error is still not enough compute or storage capacity in the datacenter to _match_ your needs. The logs will however show that the affinity rules + tags are being applied - causing no match found. 11. When a VM is in Stopped state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped. [Prachi] Good point. The association with affinity group is maintained. We never remove it unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group, on that host. So host-anti-affinity should also consider last_host_id of the VM's that are in stopped state. Thanks Sangeetha -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Friday, March
RE: [DISCUSS] Affinity / Anti-affinity Rules
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups : 1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required? 2.Can new DB changes introduced by this feature be included ? 3.CreateAffinityGroup API: Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption? 4.ListAffinityGroups API: Will admin/domain admin user be able to list the affinity groups of the other regular users ? 5.DeleteAffinityGroup API: Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group? Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ? 6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ? 7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ? 8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ? 9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ? 10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions? 11. When a VM is in Stopped state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped. Thanks Sangeetha -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Friday, March 01, 2013 2:12 PM To: cloudstack-...@incubator.apache.org Cc: Manan Shah; Alex Huang Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules On 3/1/13 7:14 AM, Chip Childers chip.child...@sungard.com wrote: On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote: So far per the scope of the feature, Affinity groups is an entity created by an individual account and can be used, listed only by that account. Wanted to know if we see any use case where one would need to create domain-level affinity groups that all accounts in that domain can access? I can see that this may not be useful, since users would want to have VM placement preferences exclusive to their accounts and not shared with other accounts. Any thoughts? I spent time thinking about this, and I'm not sure I see a use-case for it. Others might though... Me neither
RE: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1
Can we get a confirmation on the approach we want to take? 1. We are going to fix the router for the case - if the router has upgraded its scripts, and then adjust how we call edithosts.sh ? 2. Going to suggest a reboot (start and stop) of all the system Vms (SSVM,CPVM and routers) as part of Upgrade procedure? -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Wednesday, March 27, 2013 10:02 PM To: dev@cloudstack.apache.org Cc: Sangeetha Hariharan Subject: Re: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1 Ok, found the issue. The 4.0 script in the system vm that adds DHCP entries parses args like this: # edithosts.sh -- edit the dhcphosts file on the routing domain # $mac : the mac address # $ip : the associated ip address # $host : the hostname # $4 : default router # $5 : nameserver on default nic # $6 : comma separated static routes mac=$1 ip=$2 host=$3 dflt=$4 dns=$5 routes=$6 And the script in 4.1 parses args like this: while getopts 'm:4:h:d:n:s:6:u:N' OPTION do case $OPTION in m)mac=$OPTARG ;; 4)ipv4=$OPTARG ;; 6)ipv6=$OPTARG ;; u)duid=$OPTARG ;; h)host=$OPTARG ;; d)dflt=$OPTARG ;; n)dns=$OPTARG ;; s)routes=$OPTARG ;; N)nondefault=1 ;; ?)usage exit 2 ;; esac done So in 4.0 it's looking at flags as though they're arguments, which is why we get garbage in the dhcp file. In the router log we see the results (first line is a working one, second line isn't) Mar 28 04:41:54 r-5-VM cloud: edithosts: update 02:00:2b:58:00:01 10.1.1.6 ff9b5970-d095-4602-aa7d-671e3a7535da to hosts Mar 28 04:48:01 r-5-VM cloud: edithosts: update -4 10.1.1.245 -m to hosts I don't see an easy way around this. We could perhaps detect if the router has upgraded its scripts, and then adjust how we call edithosts.sh accordingly. Anyone want to take that on? Is this the only issue? I'm assuming people will need to reboot their system vms anyway for other features. On Wed, Mar 27, 2013 at 9:27 PM, Marcus Sorensen shadow...@gmail.com wrote: We can look into it, my guess is that an existing script now has new and/or different parameters. Perhaps it could be adjusted to be backward compatible so people can reboot at their leisure. All just guesswork. On Mar 27, 2013 9:21 PM, Marcus Sorensen shadow...@gmail.com wrote: Hard to say. Sometimes functionality/implementation changes even though the feature is the same. On Mar 27, 2013 9:20 PM, David Nalley da...@gnsa.us wrote: On Wed, Mar 27, 2013 at 11:13 PM, Marcus Sorensen shadow...@gmail.com wrote: Just to clarify a step further, this should have been the case with 3.x to 4.0 as well. We had all of these new vpc scripts that added brand new functionality that needed to go on the virtual routers. The system VM template stayed the same, even though new scripts were added via systemvm.iso. That said, why would new functionality make existing functionality stop working in a system VM. --David
RE: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1
Then we can go with the option of reboot (start and stop) of all the system Vms (SSVM,CPVM and routers) as part of Upgrade procedure ? -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Thursday, March 28, 2013 11:21 AM To: Chip Childers Cc: dev@cloudstack.apache.org Subject: Re: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1 I'm also not confident that option 1 really fixes anything. The user has to reboot their system VMS eventually, and even if we fix this one thing to help them get by until they do, what other lingering issues will arise? On Mar 28, 2013 11:38 AM, Chip Childers chip.child...@sungard.com wrote: On Thu, Mar 28, 2013 at 09:51:16AM -0700, Sangeetha Hariharan wrote: Can we get a confirmation on the approach we want to take? 1. We are going to fix the router for the case - if the router has upgraded its scripts, and then adjust how we call edithosts.sh ? 2. Going to suggest a reboot (start and stop) of all the system Vms (SSVM,CPVM and routers) as part of Upgrade procedure? Option 2 is my preference. Option 1 requires more testing, etc...
RE: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1
Create a doc bug for documenting these steps - CLOUDSTACK-1837 - Additonal Steps ( Restart of all system Vms , copy vhd-utils) to be included in the upgrade procedure from 4.0 - 4.1 -Thanks Sangeetha -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, March 28, 2013 12:18 PM To: Sangeetha Hariharan Cc: dev@cloudstack.apache.org Subject: Re: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1 On Thu, Mar 28, 2013 at 11:28:33AM -0700, Sangeetha Hariharan wrote: Then we can go with the option of reboot (start and stop) of all the system Vms (SSVM,CPVM and routers) as part of Upgrade procedure ? Sounds like it. Care to add a note to the release notes wiki page to this effect? -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Thursday, March 28, 2013 11:21 AM To: Chip Childers Cc: dev@cloudstack.apache.org Subject: Re: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1 I'm also not confident that option 1 really fixes anything. The user has to reboot their system VMS eventually, and even if we fix this one thing to help them get by until they do, what other lingering issues will arise? On Mar 28, 2013 11:38 AM, Chip Childers chip.child...@sungard.com wrote: On Thu, Mar 28, 2013 at 09:51:16AM -0700, Sangeetha Hariharan wrote: Can we get a confirmation on the approach we want to take? 1. We are going to fix the router for the case - if the router has upgraded its scripts, and then adjust how we call edithosts.sh ? 2. Going to suggest a reboot (start and stop) of all the system Vms (SSVM,CPVM and routers) as part of Upgrade procedure? Option 2 is my preference. Option 1 requires more testing, etc...
RE: [jira] [Created] (CLOUDSTACK-1844) Upgrade 4.0 - 4.1 - KVM host agent.properties is not restored as part of upgrading the binaries from 4.0 to 4.1.
Marcus , I did the following: Created a repo for all the new RPM from the build from 4.1 Then did yum update cloud-* After update , I see that the rpm packages have been upgraded successfully. [root@Rack3Host18 agent]# rpm -qa | grep cloud cloudstack-agent-4.1.0-SNAPSHOT.el6.x86_64 cloudstack-common-4.1.0-SNAPSHOT.el6.x86_64 [root@Rack3Host18 agent]# Attached is the agent.properties from /etc/cloudstack/agent from my host. -Thanks Sangeetha -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Thursday, March 28, 2013 6:58 PM To: dev@cloudstack.apache.org Cc: cloudstack-iss...@incubator.apache.org Subject: Re: [jira] [Created] (CLOUDSTACK-1844) Upgrade 4.0 - 4.1 - KVM host agent.properties is not restored as part of upgrading the binaries from 4.0 to 4.1. Hmm, when you say binaries are you talking about RPMs? Is this centos? I've tested 4.1 rpms and we copy the old agent.properties, everything started up fine. I'll take a look. More info on your test setup is appreciated. On Mar 28, 2013 7:43 PM, Sangeetha Hariharan (JIRA) j...@apache.org wrote: Sangeetha Hariharan created CLOUDSTACK-1844: --- Summary: Upgrade 4.0 - 4.1 - KVM host agent.properties is not restored as part of upgrading the binaries from 4.0 to 4.1. Key: CLOUDSTACK-1844 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1844 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: Upgrade from 4.0 - 41. Reporter: Sangeetha Hariharan Priority: Blocker Fix For: 4.1.0 Upgrade 4.0 - 4.1 - KVM host agent.properties is not restored as part of upgrading the binaries from 4.0 to 4.1. Install 4.1 binaries Configure Advance Zone with KVM hosts. Deploy few Vms. Stop management server. Upgrade to 4.1 binaries. Start management server. From KVM host , Stop cloud-agent. Upgrade to 4.1 binaries. Start cloud-agent. Agent fails to start because it refers to the /etc/cloudstack/agent/agent.properties which is NOT restored from the original agent.properties. Following errors seen in the agent.log: 2013-03-28 19:46:44,294 INFO [cloud.agent.AgentShell] (main:null) Agent started 2013-03-28 19:46:44,296 INFO [cloud.agent.AgentShell] (main:null) Implementation Version is 4.1.0-SNAPSHOT 2013-03-28 19:46:44,298 INFO [cloud.agent.AgentShell] (main:null) agent.properties found at /etc/cloudstack/agent/agent.properties 2013-03-28 19:46:44,299 INFO [cloud.agent.AgentShell] (main:null) Defaulting to using properties file for storage 2013-03-28 19:46:44,301 INFO [cloud.agent.AgentShell] (main:null) Defaulting to the constant time backoff algorithm 2013-03-28 19:46:44,404 INFO [cloud.agent.Agent] (main:null) id is 2013-03-28 19:46:44,466 ERROR [cloud.resource.ServerResourceBase] (main:null) Nics are not configured! 2013-03-28 19:46:44,475 INFO [cloud.resource.ServerResourceBase] (main:null) Designating private to be nic cloudbr0 2013-03-28 19:46:44,489 INFO [resource.virtualnetwork.VirtualRoutingResource] (main:null) VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm 2013-03-28 19:46:45,370 ERROR [cloud.agent.AgentShell] (main:null) Unable to start agent: Failed to get private nic name After restoring to the original agent.properties , agent is able to start successfully. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira # Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the # License); you may not use this file except in compliance # with the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, # software distributed under the License is distributed on an # AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, either express or implied. See the License for the # specific language governing permissions and limitations # under the License. # Sample configuration file for CloudStack agent # The GUID to identify the agent with, this is mandatory! # Generate with uuidgen guid= #resource= the java class, which agent load to execute resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource #workers= number of threads running in agent workers=5 #host= The IP address of management server host=localhost #port
