Re: Review Request 12545: CLOUDSTACK-1800: Add automation tests for reset sshkey to access VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12545/ --- (Updated Aug. 13, 2013, 7:41 a.m.) Review request for cloudstack, Harikrishna Patnala and Prasanna Santhanam. Bugs: CLOUDSTACK-1800 Repository: cloudstack-git Description --- CLOUDSTACK-1800: Add automation tests for reset sshkey to access VM Diffs (updated) - test/integration/component/test_reset_ssh_keypair.py PRE-CREATION Diff: https://reviews.apache.org/r/12545/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 13772: CLOUDSTACK-4144: Add free vlan to shared network in TestVMLifeCycleSharedNwVPC
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13772/ --- Review request for cloudstack, venkata swamy babu budumuru and Prasanna Santhanam. Bugs: CLOUDSTACK-4144 Repository: cloudstack-git Description --- Shared network has to have specifyVlan = True. So changed it to True and aded a function to get free vlan Diffs - test/integration/component/test_vpc_vm_life_cycle.py e612572 Diff: https://reviews.apache.org/r/13772/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 13701: Automation Tests for HA Proxy Stickiness
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13701/ --- Review request for cloudstack and Prasanna Santhanam. Repository: cloudstack-git Description --- Automation Tests for HA Proxy Stickiness Diffs - test/integration/component/test_haproxy.py PRE-CREATION Diff: https://reviews.apache.org/r/13701/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-4407 Repository: cloudstack-git Description --- Template url, hypervisor and format were defined in Service class to be Xenserver specific and therefore registering a new template failed on Vmware and KVM. Fixed this to get hypervisor specific info for registering new template. TODO: Update other tests to use the new function get_builtin_template_info Diffs - test/integration/component/test_templates.py e4599d4 tools/marvin/marvin/integration/lib/base.py b5d086b tools/marvin/marvin/integration/lib/common.py 4f5acef Diff: https://reviews.apache.org/r/13806/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
> On Aug. 27, 2013, 5:33 a.m., Prasanna Santhanam wrote: > > tools/marvin/marvin/integration/lib/base.py, line 891 > > <https://reviews.apache.org/r/13806/diff/1/?file=344716#file344716line891> > > > > extract works on an existing Image/Template. Why should it be a > > classmethod? > > > > list_template does not return template object, it returns json loader object. Therefore I had to define it a classmethod. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/#review25551 ------- On Aug. 26, 2013, 1:05 p.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13806/ > --- > > (Updated Aug. 26, 2013, 1:05 p.m.) > > > Review request for cloudstack and Prasanna Santhanam. > > > Bugs: CLOUDSTACK-4407 > > > Repository: cloudstack-git > > > Description > --- > > Template url, hypervisor and format were defined in Service class to be > Xenserver specific > and therefore registering a new template failed on Vmware and KVM. > Fixed this to get hypervisor specific info for registering new template. > > TODO: Update other tests to use the new function get_builtin_template_info > > > Diffs > - > > test/integration/component/test_templates.py e4599d4 > tools/marvin/marvin/integration/lib/base.py b5d086b > tools/marvin/marvin/integration/lib/common.py 4f5acef > > Diff: https://reviews.apache.org/r/13806/diff/ > > > Testing > --- > > > Thanks, > > Girish Shilamkar > >
Re: Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
> On Aug. 27, 2013, 5:33 a.m., Prasanna Santhanam wrote: > > tools/marvin/marvin/integration/lib/common.py, line 241 > > <https://reviews.apache.org/r/13806/diff/1/?file=344717#file344717line241> > > > > Please use Template.list. The list_templates (form of) method is > > redundant and should be deprecated. Also check that your template is > > extractable else raise an Exception. I will make it Template.list, template is registered as extractable. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/#review25551 ------- On Aug. 26, 2013, 1:05 p.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13806/ > --- > > (Updated Aug. 26, 2013, 1:05 p.m.) > > > Review request for cloudstack and Prasanna Santhanam. > > > Bugs: CLOUDSTACK-4407 > > > Repository: cloudstack-git > > > Description > --- > > Template url, hypervisor and format were defined in Service class to be > Xenserver specific > and therefore registering a new template failed on Vmware and KVM. > Fixed this to get hypervisor specific info for registering new template. > > TODO: Update other tests to use the new function get_builtin_template_info > > > Diffs > - > > test/integration/component/test_templates.py e4599d4 > tools/marvin/marvin/integration/lib/base.py b5d086b > tools/marvin/marvin/integration/lib/common.py 4f5acef > > Diff: https://reviews.apache.org/r/13806/diff/ > > > Testing > --- > > > Thanks, > > Girish Shilamkar > >
Re: Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/ --- (Updated Aug. 28, 2013, 8:02 a.m.) Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-4407 Repository: cloudstack-git Description --- Template url, hypervisor and format were defined in Service class to be Xenserver specific and therefore registering a new template failed on Vmware and KVM. Fixed this to get hypervisor specific info for registering new template. TODO: Update other tests to use the new function get_builtin_template_info Diffs (updated) - test/integration/component/test_templates.py e4599d4 tools/marvin/marvin/integration/lib/base.py b5d086b tools/marvin/marvin/integration/lib/common.py 4f5acef Diff: https://reviews.apache.org/r/13806/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 13895: CLOUDSTACK-4531: Resolved ssh error for basic zone. Public ip should be used for ssh instead of ipaddress of nic
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13895/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-4531 Repository: cloudstack-git Description --- CLOUDSTACK-4531: Resolved ssh error for basic zone. Public ip should be used for ssh instead of ipaddress of nic Diffs - tools/marvin/marvin/integration/lib/base.py 3016ee4 Diff: https://reviews.apache.org/r/13895/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
> On Aug. 29, 2013, 7:09 a.m., Prasanna Santhanam wrote: > > Do you want to fix the other test suites listed in the bug report with > > different patches? The problem with the hypervisor-specific template exists > > in other suites as in the bug report. I almost forgot about other tests to be updated. I will upload a different patch. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/#review25715 --- On Aug. 28, 2013, 8:02 a.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13806/ > --- > > (Updated Aug. 28, 2013, 8:02 a.m.) > > > Review request for cloudstack and Prasanna Santhanam. > > > Bugs: CLOUDSTACK-4407 > > > Repository: cloudstack-git > > > Description > --- > > Template url, hypervisor and format were defined in Service class to be > Xenserver specific > and therefore registering a new template failed on Vmware and KVM. > Fixed this to get hypervisor specific info for registering new template. > > TODO: Update other tests to use the new function get_builtin_template_info > > > Diffs > - > > test/integration/component/test_templates.py e4599d4 > tools/marvin/marvin/integration/lib/base.py b5d086b > tools/marvin/marvin/integration/lib/common.py 4f5acef > > Diff: https://reviews.apache.org/r/13806/diff/ > > > Testing > --- > > > Thanks, > > Girish Shilamkar > >
Re: Review Request 13895: CLOUDSTACK-4531: Resolved ssh error for basic zone. Public ip should be used for ssh instead of ipaddress of nic
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13895/ --- (Updated Sept. 3, 2013, 12:32 p.m.) Review request for cloudstack, venkata swamy babu budumuru and Prasanna Santhanam. Bugs: CLOUDSTACK-4531 Repository: cloudstack-git Description --- CLOUDSTACK-4531: Resolved ssh error for basic zone. Public ip should be used for ssh instead of ipaddress of nic Diffs (updated) - tools/marvin/marvin/integration/lib/base.py 3016ee4 Diff: https://reviews.apache.org/r/13895/diff/ Testing --- Thanks, Girish Shilamkar
Re: Passing vlan parameter to "createPortableIpRange"
Hi Swamy, Thanks for setting up a call, the other day, we were able resolve this issue quickly. In what scenario would vlan id be passed? How does passing vlan id change/affect Portable IP range to be created ? I am guessing that Portable IP range created would be within IP range assigned for the vlan. (which as of now does not work) Regards, Girish On 05-Sep-2013, at 9:41 AM, Venkata SwamyBabu Budumuru wrote: > Hi Gaurav, > > The VLAN parameter is not mandatory. Depending on your environment you can > either pass a VLAN tag / untagged one. > We have updated our documents about the issue with adding same ip range > across portable and public VLANs. This is punted for 4.2.1. > > Thanks, > SWAMY > > On 04/09/13 8:26 PM, "Gaurav Aradhye" wrote: > >> Hi Swamy, >> >> As observed, if portable ip range is created with IPs overlapping with any >> of the existing public ip ranges, then it gives "Entity already exists" >> error while associating any portable ip from the created range. (But it >> doesn't give any error while creating portable ip range in this case) >> >> The question is if we can't use IPs from existing VLANs, why to pass vlan >> parameter while creating portable ip range? Keeping the default value >> "untagged" serves the purpose and works well. I didn't get this well. >> >> Can you please explain me the how we can use vlan ids to while creating >> portable range and still get it work correctly? >> >> Regards, >> Gaurav >
FYI, issue in Portable IP feature
Hello, We found an issue while automating testcases for Portable IP. Suppose I have existing public IP range with a VLAN, and I use this range (or subset of this range) for creating a new portable IP range, portable IP range gets created successfully, but if you try to associate a portable IP to a network, it throws error saying "Entity already exists". This happens because Portable IP range should not overlap with any of existing public ip ranges (irrespective of their vlan id). Ideally, CS should not allow two public or portable IP ranges to exist within same subnet (same netmask). Each range should have different netmask (hence different subnet). This also means that two public (or portable) ranges with same start and end IPs even in different VLAN ids cannot exist. This should be fixed in the 4.2.1. https://issues.apache.org/jira/browse/CLOUDSTACK-4596 If we have to create a new portable or public IP range through code, we can't create it by finding out free IPs range in existing subnets. Hence will need to define it somewhere i.e. in the config file used by automation testcases. Regards, Girish
Review Request 14010: CLOUDSTACK-4531: Fixed indent problem with the patch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14010/ --- Review request for cloudstack, venkata swamy babu budumuru and Prasanna Santhanam. Bugs: CLOUDSTACK-4531 Repository: cloudstack-git Description --- Fixed indent error with patch Diffs - tools/marvin/marvin/integration/lib/base.py f3d57d8 Diff: https://reviews.apache.org/r/14010/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/ --- (Updated Sept. 11, 2013, 5:20 a.m.) Review request for cloudstack and Prasanna Santhanam. Changes --- Cloudstack:4407 - Pending changes - Use extractTemplate API to get hypervisor specific template information in test_accounts.py, test_blocker_bugs.py and test_stopped_vm.py Bugs: CLOUDSTACK-4407 Repository: cloudstack-git Description --- Template url, hypervisor and format were defined in Service class to be Xenserver specific and therefore registering a new template failed on Vmware and KVM. Fixed this to get hypervisor specific info for registering new template. TODO: Update other tests to use the new function get_builtin_template_info Diffs (updated) - test/integration/component/test_accounts.py 1af408e test/integration/component/test_blocker_bugs.py 2cdc270 test/integration/component/test_stopped_vm.py 41eeb46 Diff: https://reviews.apache.org/r/13806/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 13806: CLOUDSTACK-4407: Use extractTemplate API to get hypervisor specific template information
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13806/ --- (Updated Sept. 12, 2013, 9:47 a.m.) Review request for cloudstack, venkata swamy babu budumuru, SrikanteswaraRao Talluri, and Prasanna Santhanam. Bugs: CLOUDSTACK-4407 Repository: cloudstack-git Description --- Template url, hypervisor and format were defined in Service class to be Xenserver specific and therefore registering a new template failed on Vmware and KVM. Fixed this to get hypervisor specific info for registering new template. TODO: Update other tests to use the new function get_builtin_template_info Diffs - test/integration/component/test_accounts.py 1af408e test/integration/component/test_blocker_bugs.py 2cdc270 test/integration/component/test_stopped_vm.py 41eeb46 Diff: https://reviews.apache.org/r/13806/diff/ Testing --- Thanks, Girish Shilamkar
Virtual router and vm on different hosts
Hello, I was under the assumption that virtual router (VR) and vm spawned for an account would always be on the same host. Therefore in egress rule automation tests we were ssh'ing VR via host on which the vm was created. But recently we saw failures in egress rule tests as VR was not reachable from host on which vm was created. While debugging this issue I found that VR and vm for an account can be on different host. It would be great if someone could confirm this. Thanks ! Regards, Girish
Review Request 14143: CLOUDSTACK-4637: Add 30sec sleep before router is ssh'd
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14143/ --- Review request for cloudstack and venkata swamy babu budumuru. Bugs: CLOUDSTACK-4637 Repository: cloudstack-git Description --- CLOUDSTACK-4637: Add 30sec sleep before router is ssh'd Egress rules testcases access vm via router. Sleep before accessing router else the expect fails since router is not accessible. Also use router.hostid instead of vm.hostid to identify the host. Diffs - test/integration/component/test_egress_fw_rules.py ef0fc5a Diff: https://reviews.apache.org/r/14143/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 12545: CLOUDSTACK-1800: Add automation tests for reset sshkey to access VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12545/ --- (Updated Sept. 14, 2013, 7:46 a.m.) Review request for cloudstack, Harikrishna Patnala and Prasanna Santhanam. Changes --- Updated as per the review. Bugs: CLOUDSTACK-1800 Repository: cloudstack-git Description --- CLOUDSTACK-1800: Add automation tests for reset sshkey to access VM Diffs (updated) - test/integration/component/test_reset_ssh_keypair.py PRE-CREATION Diff: https://reviews.apache.org/r/12545/diff/ Testing --- Thanks, Girish Shilamkar
Re: Virtual router and vm on different hosts
Hello Marty, Marcus, Thanks for the explanation, I have updated the test accordingly. Regards, Girish On 14-Sep-2013, at 9:37 PM, Marcus Sorensen wrote: > Yes, as Marty mentions they can be on any host, with tagged vlans linking > everything together.If you prefer them on the same host you can write a > custom allocator. The user concentrated algorithm packs VMS together when > possible, and random allocator is self explanatory, but I don't think > either pay attention to the router/guest relationships. > On Sep 14, 2013 1:22 AM, "Girish Shilamkar" wrote: > >> Hello, >> >> I was under the assumption that virtual router (VR) and vm spawned for an >> account would always be on the same host. Therefore in >> egress rule automation tests we were ssh'ing VR via host on which the vm >> was created. But recently we saw failures in egress rule tests >> as VR was not reachable from host on which vm was created. While debugging >> this issue I found that VR and vm for an account can be on different host. >> It would be great if someone could confirm this. >> >> Thanks ! >> >> Regards, >> Girish >> >>
Review Request 14200: CLOUDSTACK-4686: Fixed volume limit for domain
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14200/ --- Review request for cloudstack and sailaja mada. Bugs: CLOUDSTACK-4686 Repository: cloudstack-git Description --- CLOUDSTACK-4686: Fixed volume limit for domain Diffs - test/integration/component/test_resource_limits.py 833723c Diff: https://reviews.apache.org/r/14200/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 14230: Storage type was set to local due to which tests failed.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14230/ --- Review request for cloudstack, Harikrishna Patnala and Prasanna Santhanam. Repository: cloudstack-git Description --- Storage type was set to local due to which tests failed. Diffs - test/integration/component/test_reset_ssh_keypair.py 8b499d0 Diff: https://reviews.apache.org/r/14230/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 14335: CLOUDSTACK-4262: Fix TestVPCNetworkGc.test_01_wait_network_gc
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14335/ --- Review request for cloudstack, Harikrishna Patnala and venkata swamy babu budumuru. Bugs: CLOUDSTACK-4262 Repository: cloudstack-git Description --- As per the test plan, after waiting for network gc LB rules should be cleared. Added that check instead of router being in stopped state. Diffs - test/integration/component/test_vpc_network.py 970a625 Diff: https://reviews.apache.org/r/14335/diff/ Testing --- Thanks, Girish Shilamkar
Virtual Router reachability
Hello, Egress rules tests rely on accessing virtual router VR after creating a network. I have often seen that VR is not immediately accessible. A ssh to VR fails, I think it takes a while for the network to come up and VR can be ssh'd. This happens even though the VR is in "Running" state. So I added a delay before trying to ssh VR. I was wondering what is the right amount of delay here. I did not find a param in global settings which can be used as wait time. Please advise. Regards, Girish
Re: Virtual Router reachability
Marcus, I guess it no longer applies to even KVM . I have seen the router in running state and yet fails to accept ssh connection. Santhosh, Adding random delay is what I am trying to avoid or at least minimise. Thanks for the suggestions. Regards, Girish On 30-Sep-2013, at 12:18 PM, Marcus Sorensen wrote: > In the past, with KVM, the agent doesn't show the router as running until > it can ssh to it. You can watch the agent poll if it is debug logging. Does > this issue not apply to KVM, or is it a regression? > On Sep 29, 2013 11:38 PM, "Girish Shilamkar" wrote: > >> Hello, >> >> Egress rules tests rely on accessing virtual router VR after creating a >> network. I have often seen that VR is not immediately accessible. >> A ssh to VR fails, I think it takes a while for the network to come up and >> VR can be ssh'd. This happens even though the VR is in "Running" >> state. >> So I added a delay before trying to ssh VR. I was wondering what is the >> right amount of delay here. I did not find a param in global settings >> which can be used as wait time. >> >> Please advise. >> >> Regards, >> Girish >> >>
Re: Virtual Router reachability
Indeed, thats what I had in mind. Keep trying to ssh with a suitable timeout. Thanks! Regards, Girish On 30-Sep-2013, at 2:40 PM, Jayapal Reddy Uradi wrote: > Hi Girish, > > While selecting the delay I suggest the following. > > In general check the time taken for the router boot up. > Take the max interval as 10 times of boot up time. > Repeat the ssh for each boot up interval. > > Thanks, > Jayapal > > On 30-Sep-2013, at 1:38 PM, Girish Shilamkar > wrote: > >> Marcus, >> >> I guess it no longer applies to even KVM . I have seen the router in running >> state and yet fails to accept >> ssh connection. >> >> Santhosh, >> >> Adding random delay is what I am trying to avoid or at least minimise. >> Thanks for the suggestions. >> >> Regards, >> Girish >> >> On 30-Sep-2013, at 12:18 PM, Marcus Sorensen wrote: >> >>> In the past, with KVM, the agent doesn't show the router as running until >>> it can ssh to it. You can watch the agent poll if it is debug logging. Does >>> this issue not apply to KVM, or is it a regression? >>> On Sep 29, 2013 11:38 PM, "Girish Shilamkar" wrote: >>> >>>> Hello, >>>> >>>> Egress rules tests rely on accessing virtual router VR after creating a >>>> network. I have often seen that VR is not immediately accessible. >>>> A ssh to VR fails, I think it takes a while for the network to come up and >>>> VR can be ssh'd. This happens even though the VR is in "Running" >>>> state. >>>> So I added a delay before trying to ssh VR. I was wondering what is the >>>> right amount of delay here. I did not find a param in global settings >>>> which can be used as wait time. >>>> >>>> Please advise. >>>> >>>> Regards, >>>> Girish >>>> >>>> >> >
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/ --- 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: Review Request 14335: CLOUDSTACK-4262: Fix TestVPCNetworkGc.test_01_wait_network_gc
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14335/ --- (Updated Oct. 7, 2013, 4:54 a.m.) Review request for cloudstack, Harikrishna Patnala and venkata swamy babu budumuru. Changes --- I have added the assert for netacls. But it seems the netacls are not cleared. I will file a separate defect for this. Thanks. Bugs: CLOUDSTACK-4262 Repository: cloudstack-git Description --- As per the test plan, after waiting for network gc LB rules should be cleared. Added that check instead of router being in stopped state. Diffs (updated) - test/integration/component/test_vpc_network.py 970a625 Diff: https://reviews.apache.org/r/14335/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 14469: CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py
> On Oct. 8, 2013, 12:26 a.m., sangeetha hariharan wrote: > > 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. >>1. Well on the setup on which I worked on it succeeded with just 30 secs wait. So 3 minutes timeout should be good enough ? I will add the run logs. >>2. Yes, some are also marked as TODO. I think we should just skip them for now. And we get back to them once regression pass rate is 100%. >>3. Good catch. I have fixed the testcase where vm is created with egress_policy is False and expected_result value remains same i.e. 100. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14469/#review26761 --- 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 > >
Review Request 14556: CLOUDSTACK-4766: Add timeout if vm does not reach running state
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14556/ --- Review request for cloudstack, sanjeev n and venkata swamy babu budumuru. Bugs: CLOUDSTACK-4766 Repository: cloudstack-git Description --- The test use to wait for ever for the vm to attain Running state. Added a timeout so it does not get into infinite loop. Diffs - test/integration/component/test_reset_ssh_keypair.py ace4499 Diff: https://reviews.apache.org/r/14556/diff/ Testing --- Verified that the timeout works. test_01_reset_keypair_normal_user (test_reset_ssh_keypair.TestResetSSHKeyUserRights)Verify API resetSSHKeyForVirtualMachine for non admin non root ... FAIL test_02_reset_keypair_domain_admin (test_reset_ssh_keypair.TestResetSSHKeyUserRights) Verify API resetSSHKeyForVirtualMachine for domain admin non root ... ok test_03_reset_keypair_root_admin (test_reset_ssh_keypair.TestResetSSHKeyUserRights) Verify API resetSSHKeyForVirtualMachine for domain admin root ... ok test_01_reset_ssh_keys (test_reset_ssh_keypair.TestResetSSHKeypair) Test Reset SSH keys for VM already having SSH key ... ok test_02_reset_ssh_key_password_enabled_template (test_reset_ssh_keypair.TestResetSSHKeypair) Reset SSH keys for VM created from password enabled template and ... ok test_03_reset_ssh_with_no_key (test_reset_ssh_keypair.TestResetSSHKeypair) Reset SSH key for VM having no SSH key ... ok test_04_reset_key_passwd_enabled_no_key (test_reset_ssh_keypair.TestResetSSHKeypair) Reset SSH keys for VM created from password enabled template and ... ok test_05_reset_key_in_running_state (test_reset_ssh_keypair.TestResetSSHKeypair) Reset SSH keys for VM already having SSH key when VM is in running ... ok test_06_reset_key_passwd_enabled_vm_running (test_reset_ssh_keypair.TestResetSSHKeypair) Reset SSH keys for VM created from password enabled template and ... ok test_07_reset_keypair_invalid_params (test_reset_ssh_keypair.TestResetSSHKeypair) Verify API resetSSHKeyForVirtualMachine with incorrect parameters … ok == FAIL: test_01_reset_keypair_normal_user (test_reset_ssh_keypair.TestResetSSHKeyUserRights) Verify API resetSSHKeyForVirtualMachine for non admin non root -- Traceback (most recent call last): File "/root/girish/test_reset_ssh_keypair.py", line 1218, in test_01_reset_keypair_normal_user % (vms[0].name, self.services["timeout"])) AssertionError: The virtual machine 974d1275-b747-441c-83b2-1795de4d87df failed to start even after 10 minutes ------ Thanks, Girish Shilamkar
Review Request 14557: CLOUDSTACK-4747: Rename testcase name to use lesser characters
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14557/ --- Review request for cloudstack and Sowmya Krishnan. Repository: cloudstack-git Description --- Renamed testcase name and also initialised _cleanup so that it does not break on non-NS Cloudstack setup. Diffs - test/integration/component/test_netscaler_nw_off.py 3139257 Diff: https://reviews.apache.org/r/14557/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 14556: CLOUDSTACK-4766: Add timeout if vm does not reach running state
> On Oct. 9, 2013, 11:03 a.m., sanjeev n wrote: > > Patch looks good. However still test is failing. Is it a product issue? The problem was if vm did not come up, the test went into infinite loop. Now it times out gracefully and therefore we see the failure, which is the expected output. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14556/#review26816 --- On Oct. 9, 2013, 9:50 a.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14556/ > --- > > (Updated Oct. 9, 2013, 9:50 a.m.) > > > Review request for cloudstack, sanjeev n and venkata swamy babu budumuru. > > > Bugs: CLOUDSTACK-4766 > > > Repository: cloudstack-git > > > Description > --- > > The test use to wait for ever for the vm to attain Running state. > Added a timeout so it does not get into infinite loop. > > > Diffs > - > > test/integration/component/test_reset_ssh_keypair.py ace4499 > > Diff: https://reviews.apache.org/r/14556/diff/ > > > Testing > --- > > Verified that the timeout works. > > test_01_reset_keypair_normal_user > (test_reset_ssh_keypair.TestResetSSHKeyUserRights)Verify API > resetSSHKeyForVirtualMachine for non admin non root ... FAIL > test_02_reset_keypair_domain_admin > (test_reset_ssh_keypair.TestResetSSHKeyUserRights) > Verify API resetSSHKeyForVirtualMachine for domain admin non root ... ok > test_03_reset_keypair_root_admin > (test_reset_ssh_keypair.TestResetSSHKeyUserRights) > Verify API resetSSHKeyForVirtualMachine for domain admin root ... ok > test_01_reset_ssh_keys (test_reset_ssh_keypair.TestResetSSHKeypair) > Test Reset SSH keys for VM already having SSH key ... ok > test_02_reset_ssh_key_password_enabled_template > (test_reset_ssh_keypair.TestResetSSHKeypair) > Reset SSH keys for VM created from password enabled template and ... ok > test_03_reset_ssh_with_no_key (test_reset_ssh_keypair.TestResetSSHKeypair) > Reset SSH key for VM having no SSH key ... ok > test_04_reset_key_passwd_enabled_no_key > (test_reset_ssh_keypair.TestResetSSHKeypair) > Reset SSH keys for VM created from password enabled template and ... ok > test_05_reset_key_in_running_state > (test_reset_ssh_keypair.TestResetSSHKeypair) > Reset SSH keys for VM already having SSH key when VM is in running ... ok > test_06_reset_key_passwd_enabled_vm_running > (test_reset_ssh_keypair.TestResetSSHKeypair) > Reset SSH keys for VM created from password enabled template and ... ok > test_07_reset_keypair_invalid_params > (test_reset_ssh_keypair.TestResetSSHKeypair) > Verify API resetSSHKeyForVirtualMachine with incorrect parameters … ok > > == > FAIL: test_01_reset_keypair_normal_user > (test_reset_ssh_keypair.TestResetSSHKeyUserRights) > Verify API resetSSHKeyForVirtualMachine for non admin non root > -- > Traceback (most recent call last): > File "/root/girish/test_reset_ssh_keypair.py", line 1218, in > test_01_reset_keypair_normal_user > % (vms[0].name, self.services["timeout"])) > AssertionError: The virtual machine 974d1275-b747-441c-83b2-1795de4d87df > failed to start even after 10 minutes > > -- > > > Thanks, > > Girish Shilamkar > >
Re: Review Request 13701: Automation Tests for HA Proxy Stickiness
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13701/ --- (Updated Oct. 11, 2013, 7:23 a.m.) Review request for cloudstack, suresh sadhu and Prasanna Santhanam. Repository: cloudstack-git Description --- Automation Tests for HA Proxy Stickiness Diffs (updated) - test/integration/component/test_haproxy.py PRE-CREATION Diff: https://reviews.apache.org/r/13701/diff/ Testing (updated) --- est_01_create_sticky_policy_default_values (test_haproxy.TestHAProxyStickyness) Test Configure stickiness policies with default values ... ok test_02_create_sticky_policy_custom_values (test_haproxy.TestHAProxyStickyness) Test Configure stickiness policies with custom values ... ok test_03_supported_policies_by_network (test_haproxy.TestHAProxyStickyness) Test listnetworks response to check supported stickiness policies ... ok test_04_delete_lb_rule (test_haproxy.TestHAProxyStickyness) Test LB rule before/after stickiness policy creation ... ok test_05_error_alerts_after_create (test_haproxy.TestHAProxyStickyness) Test error/alerts after creating stickiness policy ... ok test_06_release_ip (test_haproxy.TestHAProxyStickyness) Test release public IP with stickiness policy ... ok test_07_delete_account (test_haproxy.TestHAProxyStickyness) Test Delete account and check the router and its rules ... ok test_08_create_policy_router_stopped (test_haproxy.TestHAProxyStickyness) Test verify create stickiness policy when router is stopped state ... ok test_09_create_policy_router_destroy (test_haproxy.TestHAProxyStickyness) Test check the stickiness policy rules after destroying router ... ok test_10_create_policy_enable_disable_vpn (test_haproxy.TestHAProxyStickyness) Test enable/disable the VPN after applying sticky policy rules ... ok test_11_invalid_params (test_haproxy.TestHAProxyStickyness) Test verfify functionality syncronous and asyncronous validations ... ok -- Ran 11 tests in 2154.059s OK Thanks, Girish Shilamkar
Re: Review Request 14557: CLOUDSTACK-4747: Rename testcase name to use lesser characters
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14557/ --- (Updated Oct. 11, 2013, 8:31 a.m.) Review request for cloudstack, Sowmya Krishnan and SrikanteswaraRao Talluri. Changes --- Added Talluri Repository: cloudstack-git Description --- Renamed testcase name and also initialised _cleanup so that it does not break on non-NS Cloudstack setup. Diffs - test/integration/component/test_netscaler_nw_off.py 3139257 Diff: https://reviews.apache.org/r/14557/diff/ Testing --- Thanks, Girish Shilamkar
Re: [MERGE] marvin-refactor to master
Hello Prasanna, +1 to the new marvin architecture. The proposed architecture will make marvin lot more stable, remove defining data in code and will be easier to add testcases. Can we have a run in jenkins.cloudstack.org to ensure that the existing tests won't break with new marvin ? How much effort would it be to convert existing tests to use new marvin, sooner or later we might want to do it ? Going forward it will be critical to maintain these associations via factory hierarchies else would beat the purpose. And needs to be caught using reviews. In the branch what is the feature/ dir for ? Could you also put up a Todo list on the wiki ? I did not find one in the branch. Regards, Girish On 02-Oct-2013, at 10:12 PM, Prasanna Santhanam wrote: > Once upon a time [1] I had propagated the idea of refactoring marvin to > make test case writing simpler. At the time, there weren't enough > people writing tests using marvin however. Now as focus on testing has > become much more important for the stability of our releases I would > like to bring back the discussion and to review the refactoring of > marvin which I've been doing in the marvin_refactor branch. > > The key goal of this refactor was to simplify test case writing. In > doing so I've transformed the library from its brittle hand-written > nature to a completely auto-generated set of libraries. In that sense, > marvin is much closer to cloudmonkey now. > > The two important changes in this refactor are: > > 1. data represented in an object-oriented fashion presented as factories > 2. test case writing using entities and their operations rather than > a sequence of disconnected API calls. > > To see the full nature of this proposal I've updated the spec I put up > on the wiki: > https://cwiki.apache.org/confluence/x/RI3lAQ > > For a quick comparison I wrote a test for the VPC vm's lifecycle in > tools/marvin/marvin/test/test_vpc_life_cycle.py which one can compare > with the existing tests for vpc under > test/integration/component/test_vpc_vm_life_cycle.py > > These changes being 'architectural' so to speak and in a way > disruptive even I would like to merge this at the beginning of the > upcoming cloudstack release. > > This is only a small part of a larger change for marvin which will be > moving to a more BDD like implementation [2] where tests are written > using a gherkin-like language. But that will come later. > > I've also tried to disconnect marvin from depending on CloudStack's > build and repo. This will help split marvin from CloudStack which I > will discuss in a seperate thread. > > [1] http://markmail.org/message/4tsscn6zvtfsskuj > [2] http://pythonhosted.org/behave/ > > -- > Prasanna., > > > Powered by BigRock.com >
Re: Review Request: Automation: Add testcases for Affinity/Anti-Affinity Rules
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11067/ --- (Updated June 10, 2013, 10:03 a.m.) Review request for cloudstack, Prachi Damle, Prasanna Santhanam, and sangeetha hariharan. Changes --- Fixed the patch by removing trailing whitespaces Description --- Add testcases for Affinity/Anti-Affinity Rules This addresses bug CLOUDSTACK-2254. Diffs (updated) - test/integration/component/test_affinity_groups.py PRE-CREATION Diff: https://reviews.apache.org/r/11067/diff/ Testing --- The tests which are not skipped are working. Thanks, Girish Shilamkar
Review Request: CLOUDSATCK-1758: Update ssh key location for vmware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11956/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Update ssh key location for vmware This addresses bug CLOUDSTACK-1758. Diffs - tools/marvin/marvin/integration/lib/utils.py 6892c41 Diff: https://reviews.apache.org/r/11956/diff/ Testing --- Thanks, Girish Shilamkar
Review Request: CLOUDSTACK-1758: SSVM tests failed due to ssh error
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11962/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Additional fixes were needed which were found during further testing. This addresses bug CLOUDSTACK-1758. Diffs - test/integration/smoke/test_ssvm.py d637f96 Diff: https://reviews.apache.org/r/11962/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request: CLOUDSTACK-1758: SSVM tests failed due to ssh error
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11962/ --- (Updated June 19, 2013, 2:50 p.m.) Review request for cloudstack and Prasanna Santhanam. Changes --- Updated the testcase. Description --- Additional fixes were needed which were found during further testing. This addresses bug CLOUDSTACK-1758. Diffs (updated) - test/integration/smoke/test_ssvm.py d637f96 Diff: https://reviews.apache.org/r/11962/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 11067: Automation: Add testcases for Affinity/Anti-Affinity Rules
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11067/ --- (Updated June 26, 2013, 5:11 p.m.) Review request for cloudstack, Prachi Damle, sangeetha hariharan, and Prasanna Santhanam. Changes --- Latest patch for review Bugs: CLOUDSTACK-2254 Repository: cloudstack-git Description --- Add testcases for Affinity/Anti-Affinity Rules Diffs (updated) - test/integration/component/test_affinity_groups.py PRE-CREATION tools/marvin/marvin/integration/lib/base.py 503ed64 Diff: https://reviews.apache.org/r/11067/diff/ Testing --- The tests which are not skipped are working. Thanks, Girish Shilamkar
Re: Test Result for test-smoke-matrix #559
Hello Prasanna, While adding rest of the affinity rules tests I had removed affinity rules test from smoke. But while going through various iterations on the review board this hunk to remove test from smoke was dropped. The same test is now included in component. I think we should remove test_affnity_groups.py from smoke. Regards, Girish On 01-Jul-2013, at 11:37 PM, Prachi Damle wrote: > Hi Prasanna, > > For the following two test failures: > > - > integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup.test_DeployVmAntiAffinityGroup > > It looks to be some issue with the test itself. The test is failing to find > the affinity group created during the test setup. > > - > integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners.test_deployvm_userdispersing > > For the test failure about user dispersing, deployment will always succeed > due to the best-effort strategy even if it is not possible to disperse the > VMs . So we may want to remove the userdispering and userconscentrated > planner tests as they may not indicate true failures. > > Prachi > > > -Original Message- > From: Prasanna Santhanam [mailto:t...@apache.org] > Sent: Sunday, June 30, 2013 9:50 PM > To: CloudStack Dev > Subject: Re: Test Result for test-smoke-matrix #559 > > Here's the latest run, there are only 7 failures left to have a fully > successful run. > > Test Run: #561 > > Total:94 > Fail :7 > Skip :2 > > > name passfailskip > test_vm_life_cycle/ 10 0 0 > test_global_settings/ 1 0 0 > test_affinity_groups/ 0 1 0 > test_deploy_vm/ 1 0 0 > test_network_acl/ 1 0 0 > test_regions/ 1 0 0 > test_resource_detail/ 1 0 0 > test_pvlan/ 1 0 0 > test_iso/ 5 0 1 > test_deploy_vm_with_userdata/ 2 0 0 > test_routers/10 0 0 > test_disk_offerings/ 3 0 0 > test_scale_vm/0 1 0 > test_deploy_vms_with_varied_deploymentplanners/ 2 1 0 > test_templates/ 6 1 1 > test_internal_lb/ 1 0 0 > test_nic/ 1 0 0 > test_portable_publicip/ 2 0 0 > test_non_contigiousvlan/ 1 0 0 > test_ssvm/ 10 0 0 > test_network/ 7 3 0 > test_public_ip_range/ 1 0 0 > test_vm_snapshots/3 0 0 > test_volumes/ 9 0 0 > test_guest_vlan_range/1 0 0 > test_privategw_acl/ 1 0 0 > test_service_offerings/ 4 0 0 > > > > Regressions > > name > durationage > integration.smoke.test_templates.TestCreateTemplate.test_01_create_template >51.686 1 > integration.smoke.test_network.TestLoadBalancingRule.test_01_create_lb_rule_src_nat > 66.749 1 > integration.smoke.test_network.TestReleaseIP.test_releaseIP > 171.407 1 > > Failures > > name > durationage > integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup.test_DeployVmAntiAffinityGroup > 0.584 28 > integration.smoke.test_scale_vm.TestScaleVm.test_01_scale_vm > 40.644 36 > integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners.test_deployvm_userdispersing > 87.437147 > integration.smoke.test_network.TestLoadBalancingRule.test_02_create_lb_rule_non_nat >15.347 36 > > Fixed > > name > duration
Review Request 12241: CLOUDSTACK-3339: Add Vlan as true in network offering.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12241/ --- Review request for cloudstack and Prasanna Santhanam. Repository: cloudstack-git Description --- Tests in test_network_offering.py failed as Vlan option was false. Changed it to true. Diffs - test/integration/component/test_network_offering.py a3e87f6 Diff: https://reviews.apache.org/r/12241/diff/ Testing --- Thanks, Girish Shilamkar
Verifying Load Balancer logic
Hello, Some of the BVT test cases verify if load balancing rule set to round robin is working or not. It is seen that often LBing is not perfect round robin. If first request goes to one vm the next does not always go to second, when there are just two vms added to LB rule. I vaguely recall discussing this with Prasanna where he suggested removing these test cases. Prasanna, please correct me if I am wrong. Regards, Girish
Query about moving vms across domains
Hello Likitha, Some of the regression tests for changing domain membership failed. http://jenkins.buildacloud.org/job/test-regression-matrix/34/suite=test_assign_vm/testReport/ Could you please confirm my following assumptions: A domain admin can move vms only amongst its subdomains or between the its domain and subdomain. And root admin can move vms across any domains/subdomains. Is that correct ? Regards, Girish
Re: Query about moving vms across domains
Hello Likitha, Thanks! Some of the test cases fail as an exception is not raised while moving vms across subdomains under different domains. The problem is that test case uses api client with root admin privileges instead of domain admin. And therefore it does not raise exception. Regards, Girish On 09-Jul-2013, at 11:57 AM, Likitha Shetty wrote: > Hi Girish, > > Both your assumptions are right. > And going by the first assumption the test cases that are failing need to be > updated. Since the VM is being moved from a subdomain to another under the > same domain, the move should be successful and not raise an exception. > > Thanks, > Likitha > > From: Girish Shilamkar [mailto:gir...@clogeny.com] > Sent: Monday, July 08, 2013 5:28 PM > To: Likitha Shetty > Cc: dev@cloudstack.apache.org > Subject: Query about moving vms across domains > > Hello Likitha, > > Some of the regression tests for changing domain membership failed. > http://jenkins.buildacloud.org/job/test-regression-matrix/34/suite=test_assign_vm/testReport/ > > Could you please confirm my following assumptions: > A domain admin can move vms only amongst its subdomains or between the its > domain and subdomain. > And root admin can move vms across any domains/subdomains. Is that correct ? > > Regards, > Girish
Shared networks without IP range.
Hello, In order to create shared network StartIp/endIp/gateway/netmask are required. I am looking at an old test case which creates shared network without IP range and deploys vm in it. It of course fails as IP range is required while creating shared network. Has anything related to shared network changed in recent times or the test case is just invalid ? Regards, Girish
Review Request 12497: CLOUDSTACK-3340: Removed test_deployVmSharedNetworkWithoutIpRange
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12497/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3340 Repository: cloudstack-git Description --- CLOUDSTACK-3340: Removed a test which was invalid. test_deployVmSharedNetworkWithoutIpRange is invalid because StartIp/endIp/gateway/netmask are required parameters when shared network is created. Diffs - test/integration/component/test_network_offering.py a3e87f6 Diff: https://reviews.apache.org/r/12497/diff/ Testing --- Thanks, Girish Shilamkar
Re: Shared networks without IP range.
Hello Murali, Thanks for your input. I have submitted a patch to remove this test. Regards, Girish On 11-Jul-2013, at 4:41 PM, Murali Reddy wrote: > On 11/07/13 2:33 PM, "Prasanna Santhanam" wrote: > >> On Tue, Jul 09, 2013 at 12:27:28PM +0530, Girish Shilamkar wrote: >>> Hello, >>> >>> In order to create shared network StartIp/endIp/gateway/netmask are >>> required. I am looking at an old test case which creates shared >>> network without IP range >>> and deploys vm in it. It of course fails as IP range is required >>> while creating shared network. >> >>> Has anything related to shared network changed in recent times or >>> the test case is just invalid ? >> >> The steps of the test are as follows. If anyone has tested this >> scenario and/or know how this works, your input would help resolve the >> failure in automated tests: > > I am not aware of the history (2.2.x releases) but current behaviour is > you can not create a network without IP range being specified. For now > mark this test as invalid or make expected behaviour is to fail network > creation. > > Having said that, we can create network offering and network without any > network services (including DHCP, DNS). Without IPAM/DNS/DHCP services, IP > range for the network has no relevance to CloudStack. So, in my opinion > current behaviour is not right when network offering has no services, > unless there is a reason for such enforcement. Opened CLOUDSTACK-3474 for > further investigation. > >> >> If not, I'll remove this test as invalid. >> >> # 1. create a shared network using shared network offering but do not >> specify startIp/endIp arguments >> # 2. create an account >> # 3. deploy a VM in this account using the above network >> >> # Validate the following >> # 1. listNetworks should return the created network >> # 2. listAccounts to return the created account >> # 3. VM deployment should succeed and NIC is in networks address space >> # 4. delete the account >> >> >> -- >> Prasanna., >> >> >> Powered by BigRock.com >> >> > >
Re: Review Request 12497: CLOUDSTACK-3340: Removed test_deployVmSharedNetworkWithoutIpRange
> On July 12, 2013, 6:32 a.m., Prasanna Santhanam wrote: > > This test was moved to a separate suite : test_shared_network_offering.py > > Was it just moved or it was changed to. Cause in any case without ip range shared network cannot be created. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12497/#review23063 --- On July 12, 2013, 6:15 a.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12497/ > --- > > (Updated July 12, 2013, 6:15 a.m.) > > > Review request for cloudstack and Prasanna Santhanam. > > > Bugs: CLOUDSTACK-3340 > > > Repository: cloudstack-git > > > Description > --- > > > CLOUDSTACK-3340: Removed a test which was invalid. > > test_deployVmSharedNetworkWithoutIpRange is invalid because > StartIp/endIp/gateway/netmask are required parameters > when shared network is created. > > > Diffs > - > > test/integration/component/test_network_offering.py a3e87f6 > > Diff: https://reviews.apache.org/r/12497/diff/ > > > Testing > --- > > > Thanks, > > Girish Shilamkar > >
Re: [DISCUSS] If BVT breaks, revert the commits...
Alex, On 10-Jul-2013, at 9:32 AM, Alex Huang wrote: > Sorry this took a little longer than expected with the holiday in US. Here's > the first proposal [1] on the automated test system. Comments welcome. > > Specifically, I have one question on if we should have a staging branch for > all release branches and master where all checkins go and the build system > automatically cherry-pick over commits that passes the tests. +1 Staging branch is better option than to revert the commits. One useful way might be to trigger a jenkins job once a patch is uploaded to review board and run BVT. But as of now Jenkins plugin for review board does not have git support. https://wiki.jenkins-ci.org/display/JENKINS/Reviewboard+Plugin Regards, Girish > > I believe we have a lot of pieces in place. Prassana, Sudha, Rayees, Ram > Ganesh, myself, and a few others will be working to get this system in place. > > > --Alex > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Automated+Tests+Rules+and+Guidelines > >> -Original Message- >> From: David Nalley [mailto:da...@gnsa.us] >> Sent: Friday, June 28, 2013 8:44 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] If BVT breaks, revert the commits... >> >> On Fri, Jun 28, 2013 at 8:18 PM, Alex Huang wrote: >>> After Dave's complain in the vmsync [MERGE] thread about BVT in horrible >> shape on master, I went around to figure out what exactly happened. The >> best I can figure is that after a certain merge (I will leave out which >> merge as >> that's not important), BVT no longer runs automatically. It was promised to >> be fixed and there are people who are actively fixing it but it's been in >> this >> way for about two weeks. People running BVTs are working around the >> problem but it's not automated anymore and so it's no longer running on >> master. I understand people are nice and tried to be accommodating to >> other people by working around the problem but sometimes we just have to >> be an arse. So let me be that arse... >>> >>> New Rule >>> If BVT or automated regression tests break on master or any release >> branch, we revert all commits that broke it. It doesn't matter if they >> promise >> to fix it within the next hour. If it's broken, the release manager will >> revert >> the commits and developers must resubmit. It sounds mean but it's the only >> way this problem can be fixed. >>> >>> To avoid having a bunch of reverts and resubmits, the developers should >> be able to request that BVT run on their branch and don't merge until BVT on >> their branch is at 100%. We will work on figuring out how to do that. >>> >>> Comments? >>> >>> --Alex >> >> +100 - not only +100 but I will increment ASFBots $beverage counter a >> few in your favor for suggesting this. >> >> --David
Review Request 12545: CLOUDSTACK-1800: Add automation tests for reset sshkey to access VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12545/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-1800 Repository: cloudstack-git Description --- CLOUDSTACK-1800: Add automation tests for reset sshkey to access VM Diffs - test/integration/component/test_reset_ssh_keypair.py PRE-CREATION Diff: https://reviews.apache.org/r/12545/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 12661: CLOUDSTACK-3586: Fixed few failures in regression tests in Affinity Groups
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12661/ --- Review request for cloudstack, Prachi Damle and Prasanna Santhanam. Bugs: CLOUDSTACK-3586 Repository: cloudstack-git Description --- CLOUDSTACK-3586: Fixed few failures in regression tests in Affinity Groups Diffs - test/integration/component/test_affinity_groups.py 44bf90c tools/marvin/marvin/integration/lib/base.py bc8c603 Diff: https://reviews.apache.org/r/12661/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 12812: CLOUDSTACK-3610: Fix regression test "test_accounts.TestUserLogin"
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12812/ --- Review request for cloudstack, Parth Jagirdar and Prasanna Santhanam. Bugs: CLOUDSTACK-3610 Repository: cloudstack-git Description --- Now password is sent as clear text as per CLOUDSTACK-1734. So changed marvin to handle this. Plus domainid was not passed in the testcase and marvin used "domainid" instead of "domainId" as a parameter. Fixed these two errors. Diffs - test/integration/component/test_accounts.py 65c0c6f tools/marvin/marvin/integration/lib/base.py bc8c603 Diff: https://reviews.apache.org/r/12812/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 12897: CLOUDSTACK-3594: Fix regression in Affinity Groups tests
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12897/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3594 Repository: cloudstack-git Description --- One of the patches introduced a regression where account and domainid parameters were changed. Therefore Affinity Groups for those accounts were not found and tests failed. Diffs - tools/marvin/marvin/integration/lib/base.py 6e49ae5 Diff: https://reviews.apache.org/r/12897/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 12942: CLOUDSTACK-3454: Fix test_portable_publicip
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12942/ --- Review request for cloudstack, Murali Reddy and Prasanna Santhanam. Bugs: CLOUDSTACK-3454 Repository: cloudstack-git Description --- Added isportable param to associateIP API. Fixed base class for PortableIP tio call portableip APIs. Removed test_createPortablePublicIPAcquire from basic zone run requires additional network creation handling which can be done in component tests. Diffs - test/integration/smoke/test_portable_publicip.py 9a3a398 tools/marvin/marvin/integration/lib/base.py 0f6fdc5 Diff: https://reviews.apache.org/r/12942/diff/ Testing --- Yes, but disassociating ip address fails. Maybe a product defect, yet to investigate. Thanks, Girish Shilamkar
Review Request 12962: CLOUDSTACK-3594: Fix params of AffinityGroup.delete API
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12962/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3594 Repository: cloudstack-git Description --- CLOUDSTACK-3594: Fix params of AffinityGroup.delete API Diffs - test/integration/component/test_affinity_groups.py 3f257c3 Diff: https://reviews.apache.org/r/12962/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 12962: CLOUDSTACK-3594: Fix params of AffinityGroup.delete API
> On July 26, 2013, 8:21 a.m., Prasanna Santhanam wrote: > > I've changed the library method to only accept delete by id last night. Can > > you reuse that? We need to keep the delete operations consistent across the > > integration library. > > If a custom delete is required, then that can be handled within the test. > > > > So this test will fail with the latest marvin I think most of the tests will fail in that case. I will fix them. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12962/#review23918 ------- On July 26, 2013, 7:42 a.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12962/ > --- > > (Updated July 26, 2013, 7:42 a.m.) > > > Review request for cloudstack and Prasanna Santhanam. > > > Bugs: CLOUDSTACK-3594 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-3594: Fix params of AffinityGroup.delete API > > > Diffs > - > > test/integration/component/test_affinity_groups.py 3f257c3 > > Diff: https://reviews.apache.org/r/12962/diff/ > > > Testing > --- > > > Thanks, > > Girish Shilamkar > >
Create Affinity Group API
Hello,
While testing Affinity Groups feature I found that createAffinityGroups API
does not return "id" in response.
2013-07-29 12:17:16,641 INFO [cloud.api.ApiServer] (catalina-exec-24:null)
(userId=2 accountId=2 sessionId=72E8E1EE5D2EC61E90BE7F944D3EA4FC)
192.168.100.53 -- GET
command=createAffinityGroup&response=json&sessionkey=Hdq5ogh%2Fc2A5PXXrJDNd2SkwBvU%3D&name=Test_g&type=host+anti-affinity&_=1375080436560
200 { "createaffinitygroupresponse" :
{"id":"366e51ce-ce6d-41d9-9ea1-dfd932962bdc","jobid":"fba998cc-9285-421b-9a57-8fd3f9fae7a4"}
}
2013-07-29 12:17:19,668 INFO [cloud.api.ApiServer] (catalina-exec-21:null)
(userId=2 accountId=2 sessionId=72E8E1EE5D2EC61E90BE7F944D3EA4FC)
192.168.100.53 -- GET
command=queryAsyncJobResult&jobId=fba998cc-9285-421b-9a57-8fd3f9fae7a4&response=json&sessionkey=Hdq5ogh%2Fc2A5PXXrJDNd2SkwBvU%3D&_=1375080439598
200 { "queryasyncjobresultresponse" :
{"accountid":"4bc23192-f4f5-11e2-bf57-005056860002","userid":"4bc28d0e-f4f5-11e2-bf57-005056860002","cmd":"org.apache.cloudstack.api.command.user.affinitygroup.CreateAffinityGroupCmd","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"affinitygroup":{"name":"Test_g","account":"admin","domainid":"3d051818-f4f5-11e2-bf57-005056860002","domain":"ROOT","type":"host
anti-affinity"}},"created":"2013-07-29T12:17:16+0530","jobid":"fba998cc-9285-421b-9a57-8fd3f9fae7a4"}
}
I have filed a defect for it.
https://issues.apache.org/jira/browse/CLOUDSTACK-3889
Regards,
Girish
Review Request 13056: CLOUDSTACK-3168: Fix test_reboot_router.py to ssh using public IP
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13056/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3168 Repository: cloudstack-git Description --- test_reboot_router.py was trying to ssh to vm using private IP and hence it failed with error "No route to host." Fixed the testcase to ssh using public IP. Diffs - test/integration/smoke/test_network.py dad5630 Diff: https://reviews.apache.org/r/13056/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 13375: CLOUDSTACK-4144 Make specifyVlan to false for shared network
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13375/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-4144 Repository: cloudstack-git Description --- CLOUDSTACK-4144 Make specifyVlan to false for shared network Diffs - test/integration/component/test_vpc_vm_life_cycle.py 9b10133 Diff: https://reviews.apache.org/r/13375/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 13378: Test assumes storagetype to be local therefore test_egress_fw_rules fail.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13378/ --- Review request for cloudstack, Ashutosh Kelkar and Prasanna Santhanam. Repository: cloudstack-git Description --- Test assumes storagetype to be local therefore test_egress_fw_rules fail. Removed storagetype definition. Diffs - test/integration/component/test_egress_fw_rules.py 6f511e5 Diff: https://reviews.apache.org/r/13378/diff/ Testing --- Thanks, Girish Shilamkar
Review Request: Automation tests for reset ssh key for access to VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10335/ --- Review request for cloudstack. Description --- Automation tests for Reset SSH key for access to VM https://issues.apache.org/jira/browse/CLOUDSTACK-1800 Diffs - test/integration/component/test_reset_ssh_keypair.py PRE-CREATION Diff: https://reviews.apache.org/r/10335/diff/ Testing --- Done. Thanks, Girish Shilamkar
Re: Review Request: Automation tests to qualify user provided hostname feature.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10793/ --- (Updated April 26, 2013, 7:14 p.m.) Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Changes --- Adding the cloudstack group so this is available to the list. I'm assuming this is related to CLOUDSTACK-778. Change the assigned bug if that's not the case. Description --- Automation tests to qualify User provides hostname feature. 1. Defines services class 2. Test to verify custom hostname for the instance with internal name 3. Test to verify custom hostname for the instance without internal name This addresses bug CLOUDSTACK-778. Diffs (updated) - test/integration/component/test_custom_hostname.py PRE-CREATION Diff: https://reviews.apache.org/r/10793/diff/ Testing --- Tested and works fine. Thanks, Girish Shilamkar
Re: Review Request: Automation tests to qualify user provided hostname feature.
> On April 26, 2013, 10:42 a.m., Prasanna Santhanam wrote: > > test/integration/component/test_custom_hostname.py, line 265 > > <https://reviews.apache.org/r/10793/diff/1/?file=284685#file284685line265> > > > > How's this test different from the previous one? Should the setting be > > false? It looks like you are testing for the negative result? The flag is true but we don't provide the hostname so it should pick up the configured instance name. There are different set of tests where flag is false. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10793/#review19762 ------- On April 26, 2013, 7:14 p.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10793/ > --- > > (Updated April 26, 2013, 7:14 p.m.) > > > Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao > Talluri. > > > Description > --- > > Automation tests to qualify User provides hostname feature. > 1. Defines services class > 2. Test to verify custom hostname for the instance with internal name > 3. Test to verify custom hostname for the instance without internal name > > > This addresses bug CLOUDSTACK-778. > > > Diffs > - > > test/integration/component/test_custom_hostname.py PRE-CREATION > > Diff: https://reviews.apache.org/r/10793/diff/ > > > Testing > --- > > Tested and works fine. > > > Thanks, > > Girish Shilamkar > >
Review Request: Add vpn users automation tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10816/ --- Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Description --- Contains all tests which can be automated from this test plan http://wiki.cloudstack.org/display/QA/VPN+users Diffs - test/integration/component/test_vpn_users.py PRE-CREATION Diff: https://reviews.apache.org/r/10816/diff/ Testing --- Tested and verified. Thanks, Girish Shilamkar
Re: Review Request: Add vpn users automation tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10816/ --- (Updated April 27, 2013, 8:10 a.m.) Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Description --- Contains all tests which can be automated from this test plan http://wiki.cloudstack.org/display/QA/VPN+users Diffs - test/integration/component/test_vpn_users.py PRE-CREATION Diff: https://reviews.apache.org/r/10816/diff/ Testing --- Tested and verified. Thanks, Girish Shilamkar
Review Request: Automation: Add testcases for Affinity/Anti-Affinity Rules
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11067/ --- Review request for cloudstack, Prasanna Santhanam and sangeetha hariharan. Description --- Add testcases for Affinity/Anti-Affinity Rules This addresses bug CLOUDSTACK-2254. Diffs - test/integration/smoke/test_affinity_groups.py e0e1a17 tools/marvin/marvin/integration/lib/base.py ecdc841 Diff: https://reviews.apache.org/r/11067/diff/ Testing --- The tests which are not skipped are working. Thanks, Girish Shilamkar
Review Request: Fix CLOUDSTACK-2513 VPN tests refer to invalid connection.user in cloudConnection
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11179/ --- Review request for cloudstack and Prasanna Santhanam. Description --- cloudConnection object should always have "user" and "passwd" attributes. And they are "None" while creating userAPIClient. As we already have "user" and "password" for mgmt server. This addresses bug CLOUDSTACK-2513. Diffs - tools/marvin/marvin/cloudstackConnection.py b5ff5bf Diff: https://reviews.apache.org/r/11179/diff/ Testing --- Thanks, Girish Shilamkar
Marvin listPortForwardingRules API
Hello Prasanna, Tests using listportforwardingrules are failing with latest marvin. listportforwardingrules failed, due to: errorCode: 431, errorText:Unable to execute API command listportforwardingrules due to invalid value. Invalid parameter id value=c9373d55-3d01-480d-98dc-2365d3927378 due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. I checked the listPortForwardingRules.py and found that "class tags" was added to this file resulting in the above failure. Marvin APIs are built from serverside API not sure how this "class tags" got added here. I have filed a bug: https://issues.apache.org/jira/browse/CLOUDSTACK-2577 Regards, Girish
Re: Review Request: Automation: Add testcases for Affinity/Anti-Affinity Rules
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11067/ --- (Updated May 21, 2013, 8:04 a.m.) Review request for cloudstack, Prasanna Santhanam and sangeetha hariharan. Changes --- Moved the tests from smoke to component. Description --- Add testcases for Affinity/Anti-Affinity Rules This addresses bug CLOUDSTACK-2254. Diffs (updated) - test/integration/component/test_affinity_groups.py PRE-CREATION tools/marvin/marvin/integration/lib/base.py ec1c34e Diff: https://reviews.apache.org/r/11067/diff/ Testing --- The tests which are not skipped are working. Thanks, Girish Shilamkar
Re: Review Request: Automation tests to qualify user provided hostname feature.
> On April 26, 2013, 10:42 a.m., Prasanna Santhanam wrote: > > test/integration/component/test_custom_hostname.py, line 265 > > <https://reviews.apache.org/r/10793/diff/1/?file=284685#file284685line265> > > > > How's this test different from the previous one? Should the setting be > > false? It looks like you are testing for the negative result? > > Girish Shilamkar wrote: > The flag is true but we don't provide the hostname so it should pick up > the configured instance name. There are different set of tests where flag is > false. > > Prasanna Santhanam wrote: > I see now in the comments. Can you change the names of the tests thus? > test_01_user_provided_hostname(self) > """Test for user provided hostname to an instance > """ > > test_02_instancename_from_default_configuration(self) > """Test for globally set instancename > """ > > When the tests are run it is hard to distinguish between the tests > without this information from the logs output by our testrunner.. > > Fixed. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10793/#review19762 --- On April 26, 2013, 7:14 p.m., Girish Shilamkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10793/ > --- > > (Updated April 26, 2013, 7:14 p.m.) > > > Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao > Talluri. > > > Description > --- > > Automation tests to qualify User provides hostname feature. > 1. Defines services class > 2. Test to verify custom hostname for the instance with internal name > 3. Test to verify custom hostname for the instance without internal name > > > This addresses bug CLOUDSTACK-778. > > > Diffs > - > > test/integration/component/test_custom_hostname.py PRE-CREATION > > Diff: https://reviews.apache.org/r/10793/diff/ > > > Testing > --- > > Tested and works fine. > > > Thanks, > > Girish Shilamkar > >
Re: Review Request: Automation tests to qualify user provided hostname feature.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10793/ --- (Updated May 21, 2013, 11:01 a.m.) Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Changes --- Changed the patch as per review. Description --- Automation tests to qualify User provides hostname feature. 1. Defines services class 2. Test to verify custom hostname for the instance with internal name 3. Test to verify custom hostname for the instance without internal name This addresses bug CLOUDSTACK-778. Diffs (updated) - test/integration/component/test_custom_hostname.py PRE-CREATION Diff: https://reviews.apache.org/r/10793/diff/ Testing --- Tested and works fine. Thanks, Girish Shilamkar
Review Request: Fix unresolved max_value in test_project_limits.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11303/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Fix unresolved max_value in test_project_limits.py This addresses bug CLOUDSTACK-2472. Diffs - test/integration/component/test_project_limits.py 17ddfc6 Diff: https://reviews.apache.org/r/11303/diff/ Testing --- Thanks, Girish Shilamkar
Review Request: Fix a typo in test_vpc_network.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11304/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Fix a typo in test_vpc_network.py This addresses bug CLOUDSTACK-2473. Diffs - test/integration/component/test_vpc_network.py dc53585 Diff: https://reviews.apache.org/r/11304/diff/ Testing --- Thanks, Girish Shilamkar
Review Request: CS-2474: Remove garbage code which was added while resolving merge conflicts.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11306/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Remove garbage code which was added while resolving merge conflicts. This addresses bug CLOUDSTACK-2474. Diffs - test/integration/component/test_vpc_routers.py 763a4cb Diff: https://reviews.apache.org/r/11306/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request: CS-2474: Remove garbage code which was added while resolving merge conflicts.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11306/ --- (Updated May 21, 2013, 11:45 a.m.) Review request for cloudstack and Prasanna Santhanam. Description --- Remove garbage code which was added while resolving merge conflicts. This addresses bug CLOUDSTACK-2474. Diffs - test/integration/component/test_vpc_routers.py 763a4cb Diff: https://reviews.apache.org/r/11306/diff/ Testing --- Thanks, Girish Shilamkar
assignVirtualMachine API fails
Hello, While writing automation tests Changing account membership for VMs, assignVirtualMachine API fails with errorCode: 530, errorText:Failed to move vm Remove the Port forwarding rules for this VM before assigning to another user. This happens even though vm wasn't set any PF rule. We saw this on CloudStack-non-OSS-MASTER-373-rhel6.3 Has anyone seen this problem before ? PFA, management server log. Regards, Girish
Review Request: CLOUDSTACK-2577: Fix exception handling for listPortForwarding API
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11328/ --- Review request for cloudstack and Prasanna Santhanam. Description --- listPortForwarding API returns an exception if the PF is deleted. Changed testcases to handle this exception. This addresses bug CLOUDSTACK-2577. Diffs - test/integration/smoke/test_network.py 4a7bb44 Diff: https://reviews.apache.org/r/11328/diff/ Testing --- Thanks, Girish Shilamkar
Re: assignVirtualMachine API fails
+Ashutosh. On Wed, May 22, 2013 at 6:42 PM, Likitha Shetty wrote: > Girish, > > ** ** > > I am not able to reproduce this on master. Can you double check if port > forwarding has not been set on the VM? > > And if a PF rule has been configured then it is the expected behavior. > > ** ** > > Thanks, > > Likitha **** > > ** ** > > *From:* Girish Shilamkar [mailto:gir...@clogeny.com] > *Sent:* Wednesday, May 22, 2013 12:40 PM > *To:* dev@cloudstack.apache.org > *Cc:* Likitha Shetty; Parth Jagirdar > *Subject:* assignVirtualMachine API fails > > ** ** > > Hello, > > ** ** > > While writing automation tests Changing account membership for VMs, > assignVirtualMachine API fails with > > ** ** > > errorCode: 530, errorText:Failed to move vm Remove the Port forwarding > rules for this VM before assigning to another user. > > ** ** > > This happens even though vm wasn't set any PF rule. We saw this > on CloudStack-non-OSS-MASTER-373-rhel6.3 > > ** ** > > Has anyone seen this problem before ? > > ** ** > > PFA, management server log. > > ** ** > > ** ** > > Regards, > > Girish > > ** ** > > ** ** >
Re: Review Request: Automation: Add testcases for Affinity/Anti-Affinity Rules
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11067/ --- (Updated May 29, 2013, 7:46 a.m.) Review request for cloudstack, Prachi Damle, Prasanna Santhanam, and sangeetha hariharan. Changes --- Updated the patch so that only testcases related to createAffinityGroups API are in the patch. Description --- Add testcases for Affinity/Anti-Affinity Rules This addresses bug CLOUDSTACK-2254. Diffs (updated) - test/integration/component/test_affinity_groups.py PRE-CREATION test/integration/smoke/test_affinity_groups.py e0e1a17 tools/marvin/marvin/integration/lib/base.py ec1c34e Diff: https://reviews.apache.org/r/11067/diff/ Testing --- The tests which are not skipped are working. Thanks, Girish Shilamkar
Re: Review Request: Automation: Add testcases for Affinity/Anti-Affinity Rules
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11067/ --- (Updated May 29, 2013, 7:56 a.m.) Review request for cloudstack, Prachi Damle, Prasanna Santhanam, and sangeetha hariharan. Changes --- Update the patches with testcases for listAffinityGroups API Description --- Add testcases for Affinity/Anti-Affinity Rules This addresses bug CLOUDSTACK-2254. Diffs (updated) - test/integration/component/test_affinity_groups.py PRE-CREATION Diff: https://reviews.apache.org/r/11067/diff/ Testing --- The tests which are not skipped are working. Thanks, Girish Shilamkar
Re: Review Request 19993: CLOUDSTACK-5674: Minor fixes to BVT test cases in marvin branch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19993/#review39525 --- Ship it! Ship It! - Girish Shilamkar On April 3, 2014, 12:28 p.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19993/ > --- > > (Updated April 3, 2014, 12:28 p.m.) > > > Review request for cloudstack and Girish Shilamkar. > > > Bugs: CLOUDSTACK-5674 > https://issues.apache.org/jira/browse/CLOUDSTACK-5674 > > > Repository: cloudstack-git > > > Description > --- > > Minor fixes to few BVT test cases such as > 1. Correcting the method call to getZoneForTests > 2. Adding list validation > 3. Removing services["mode"]. Reading it from zone.networktype > > > Diffs > - > > test/integration/smoke/test_network.py dc2e53e > test/integration/smoke/test_public_ip_range.py ca3c83b > test/integration/smoke/test_secondary_storage.py d430beb > test/integration/smoke/test_vm_snapshots.py ca6af31 > > Diff: https://reviews.apache.org/r/19993/diff/ > > > Testing > --- > > Yes > > > Thanks, > > Gaurav Aradhye > >
Re: Review Request 21009: Added Network API tests to test_escalation.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21009/#review42401 --- Could you please rebase the patch to 4.4-forward ? - Girish Shilamkar On May 2, 2014, 8:35 a.m., Anish Bindal wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21009/ > --- > > (Updated May 2, 2014, 8:35 a.m.) > > > Review request for cloudstack and Santhosh Edukulla. > > > Bugs: CLOUDSTACK-6282 > https://issues.apache.org/jira/browse/CLOUDSTACK-6282 > > > Repository: cloudstack-git > > > Description > --- > > Added Network API tests to test_escalation.py > > > Diffs > - > > test/integration/component/test_escalations.py e994579 > tools/marvin/marvin/config/test_data.py b862205 > > Diff: https://reviews.apache.org/r/21009/diff/ > > > Testing > --- > > Executed all tests and attached are the result log files. > > > File Attachments > > > Result Log File > > https://reviews.apache.org/media/uploaded/files/2014/05/02/d76abc1c-95c0-4ad5-93f2-38ebb5d85763__results.txt > > > Thanks, > > Anish Bindal > >
Re: Review Request 21263: CLOODSTACK-6282: Added tests to IP Addess and divided test_escalations into individual files
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21263/#review43358 --- Master: author vinayvarmav Mon, 19 May 2014 11:16:06 + (16:16 +0530) committer Girish Shilamkar Mon, 19 May 2014 06:15:17 + (02:15 -0400) commit ef2012677c8eb47e083a7220dfc30ac001e91567 tree069cc35e4e03d69bc910f4b358f5a7fe01fc2e1btree | snapshot parent b4ad709d321b79f532721cd65f9ecf9584d68ee6 4.4-forward: author vinayvarmav Mon, 19 May 2014 11:16:06 + (16:16 +0530) committer Girish Shilamkar Mon, 19 May 2014 06:17:09 + (02:17 -0400) commit 378e1da42c235d310df3d39d3d82270ef00546df tree428301c4eb8dbaff175a007cf43c2c8027d66cd3tree | snapshot parent d43d28ee84424359d5847fa6e53dabad176f037e - Girish Shilamkar On May 19, 2014, 11:21 a.m., Vinay Varma wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21263/ > --- > > (Updated May 19, 2014, 11:21 a.m.) > > > Review request for cloudstack and Santhosh Edukulla. > > > Bugs: CLOUDSTACK-6282 > https://issues.apache.org/jira/browse/CLOUDSTACK-6282 > > > Repository: cloudstack-git > > > Description > --- > > CLOODSTACK-6282: Added tests to IP Addess and divided test_escalations into > individual files based on their functionality > > Executed the tests in master and 4.4-forward branch and are running fine. > Attached are the results files for each of the .py file in master and in > 4.4-forward branches > > > Diffs > - > > test/integration/component/test_escalations_instances.py PRE-CREATION > test/integration/component/test_escalations_ipaddresses.py PRE-CREATION > test/integration/component/test_escalations_isos.py PRE-CREATION > test/integration/component/test_escalations_securitygroups.py PRE-CREATION > test/integration/component/test_escalations_snapshots.py PRE-CREATION > test/integration/component/test_escalations_templates.py PRE-CREATION > test/integration/component/test_escalations_volumes.py PRE-CREATION > test/integration/component/test_escalations_vpncustomergateways.py > PRE-CREATION > tools/marvin/marvin/lib/base.py 0a6405d > > Diff: https://reviews.apache.org/r/21263/diff/ > > > Testing > --- > > Executed the tests in master and 4.4-forward branch and are running fine. > Attached are the results files for each of the .py file in master and in > 4.4-forward branches > > > File Attachments > > > MasterResults-Instances.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/406e33de-cc24-40e3-84c1-5a6d65a5d148__MasterResults-Instances.txt > MasterResults-IpAddresses.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/dab25ce0-3d8b-450e-a5d7-8319b3222080__MasterResults-IpAddresses.txt > MasterResults-Isos.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/55ef7b92-ba30-4297-9518-ea41dfa3b873__MasterResults-Isos.txt > MasterResults-SecurityGroups.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/db59e0ec-3980-4486-92aa-9f9ca07619dc__MasterResults-SecurityGroups.txt > MasterResults-Snapshots.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/0f1303df-00dd-4535--f8fe24fb00ec__MasterResults-Snapshots.txt > MasterResults-Templates.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/27803766-d7d5-477a-9cb4-00af19707268__MasterResults-Templates.txt > MasterResults-VPNCustomerGateway.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/fb836ae9-030d-4e47-b482-8329fd891415__MasterResults-VPNCustomerGateway.txt > MasterResults-Volumes.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/948f0888-ceac-4202-a430-4e3fb426bc9d__MasterResults-Volumes.txt > 4.4Results-Instances.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/31828ac7-98d9-4f18-a82b-4802e798573e__4.4Results-Instances.txt > 4.4Results-IpAddresses.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/4f450475-1fbf-4883-8c7c-5594b01fcc94__4.4Results-IpAddresses.txt > 4.4Results-Isos.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/31c9fc6e-2a82-4dc6-9e22-1ec8b4752695__4.4Results-Isos.txt > 4.4Results-SecurityGroups.txt > > https://reviews.apache.org/media/uploaded/files/2014/05/09/dcd978be-178b-4ef8-b98b-b685b688478f__4.4Results-SecurityG
Re: Review Request 21905: Fixing syntax error in base library
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21905/#review43920 --- Ship it! Ship It! - Girish Shilamkar On May 26, 2014, 9:13 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21905/ > --- > > (Updated May 26, 2014, 9:13 a.m.) > > > Review request for cloudstack and Santhosh Edukulla. > > > Repository: cloudstack-git > > > Description > --- > > Removing the extra comma > > > Diffs > - > > tools/marvin/marvin/lib/base.py 83233dd > > Diff: https://reviews.apache.org/r/21905/diff/ > > > Testing > --- > > Tested with python command and pyflakes. > > > Thanks, > > Gaurav Aradhye > >
Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/#review45609 --- Ship it! Ship It! - Girish Shilamkar On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22549/ > --- > > (Updated June 13, 2014, 7:42 a.m.) > > > Review request for cloudstack and Girish Shilamkar. > > > Bugs: CLOUDSTACK-6887 > https://issues.apache.org/jira/browse/CLOUDSTACK-6887 > > > Repository: cloudstack-git > > > Description > --- > > Fixing account cleanup issues across multiple test cases. This patch contains > test cases fixes in 8 test suites. Will put up new patch for remaining test > suites as and when I fix them. > > > Diffs > - > > test/integration/component/test_add_remove_network.py 20aefe4 > test/integration/component/test_persistent_networks.py ab1e2c2 > test/integration/component/test_projects.py c593fb6 > test/integration/component/test_snapshot_gc.py 42c361c > test/integration/component/test_snapshot_limits.py 95c6432 > test/integration/component/test_usage.py 03823be > test/integration/component/test_volumes.py b5b08e2 > test/integration/smoke/test_affinity_groups.py 4f3f9ec > > Diff: https://reviews.apache.org/r/22549/diff/ > > > Testing > --- > > Tested on VMware. > > > Thanks, > > Gaurav Aradhye > >
Re: Review Request 20316: CLOUDSTACK-1466: Adding automation test cases for Primary Storage Limits
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20316/#review45925 --- Ship it! Ship It! - Girish Shilamkar On June 6, 2014, 9:40 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/20316/ > --- > > (Updated June 6, 2014, 9:40 a.m.) > > > Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. > > > Bugs: CLOUDSTACK-1466 > https://issues.apache.org/jira/browse/CLOUDSTACK-1466 > > > Repository: cloudstack-git > > > Description > --- > > Adding test suits in Primary Storage Limits test cases. > 1)Root/Domain admin limits > 2)Domain Limits > 3)Resize volume > 4)Project Limits > 5)Maximum Limits > > > Diffs > - > > test/integration/component/test_ps_domain_limits.py PRE-CREATION > test/integration/component/test_ps_limits.py PRE-CREATION > test/integration/component/test_ps_max_limits.py PRE-CREATION > test/integration/component/test_ps_project_limits.py PRE-CREATION > test/integration/component/test_ps_resize_volume.py PRE-CREATION > tools/marvin/marvin/codes.py ef49c0c > tools/marvin/marvin/lib/base.py 2681724 > tools/marvin/marvin/lib/common.py 91fe053 > > Diff: https://reviews.apache.org/r/20316/diff/ > > > Testing > --- > > Yes > > > Thanks, > > Gaurav Aradhye > >
Shrink data volume support
The specifications at [1] show that data volume shrink is only supported on KVM and that too for QCOW2 disk types. However, I see the option to shrink on VMware too. Can anybody point me to the matrix which specifies grow/shrink support per hypervisor type? Currently I am seeing "unexpected exception" while trying to shrink Data volume on both the hypervisors, and it's a null pointer exception. I will log a bug for this and keep you posted. Mean while please share if this is known issue or it's not supported. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Resize+Data+Volumes Regards, Girish
Re: Review Request 22934: CLOUDSTACK-6984: Fixing few issues found durign simulator run
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22934/#review46530 --- Ship it! Ship It! - Girish Shilamkar On June 24, 2014, 3:04 p.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22934/ > --- > > (Updated June 24, 2014, 3:04 p.m.) > > > Review request for cloudstack and Girish Shilamkar. > > > Bugs: CLOUDSTACK-6984 > https://issues.apache.org/jira/browse/CLOUDSTACK-6984 > > > Repository: cloudstack-git > > > Description > --- > > Fixing issues found in simulator run. > > 1. test_01_stop_vm failed on simulator because of escape sequences present in > the response from simulator > 2. test_releaseIP failed due to incorrect listing of IP address. The IP > address which was was associated was not listed exactly (Listed by passing > account id and domain id which listed other IP addresses associated with the > account along with desired IP). The IP address which is not used for source > nat should get listed instead. > > > Diffs > - > > test/integration/smoke/test_network.py 0ae777e > test/integration/smoke/test_vm_life_cycle.py 9ab7848 > tools/marvin/marvin/lib/base.py c3d98c9 > > Diff: https://reviews.apache.org/r/22934/diff/ > > > Testing > --- > > yes. > > > Thanks, > > Gaurav Aradhye > >
Re: Review Request 22955: CLOUDSTACK-6985: Re-enabling test_02_deploy_vm_root_resize
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22955/#review46721 --- Ship it! Ship It! - Girish Shilamkar On June 25, 2014, 1:32 p.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22955/ > --- > > (Updated June 25, 2014, 1:32 p.m.) > > > Review request for cloudstack and Girish Shilamkar. > > > Repository: cloudstack-git > > > Description > --- > > Enabling test case test_02_deploy_vm_root_resize, as the issue is not > reproducible. > > > Diffs > - > > test/integration/smoke/test_deploy_vm_root_resize.py 269b321 > > Diff: https://reviews.apache.org/r/22955/diff/ > > > Testing > --- > > > Thanks, > > Gaurav Aradhye > >
Re: Http connection failure in marvin
I have been hitting this issue quite often since couple of weeks. I just switched the management server and so far haven't seen it. Maybe updating httplib might help. Regards, Girish On 16-Oct-2013, at 11:04 AM, Prasanna Santhanam wrote: > On Wed, Oct 16, 2013 at 05:11:46AM +, Girish Shilamkar wrote: >> Hello, >> >> Sometimes while running automation testcases tests just fail with following >> error: >> >> ConnectionError: HTTPConnectionPool(host='10.147.59.65', port=8080): >> Max retries exceeded with url: /client/api? >> apiKey=lcgWQ9XrjyIyPjsl7Y0BGI2udSRMs6S1w_42lWkwpCSfLWjkgoWvCakWwUCJ3TqfgMmuHWT4DXv5Lgoz-KCuSQ&egressdefaultpolicy=true&serviceproviderlist%5B2%5D. >> provider=VirtualRouter&serviceproviderlist%5B5%5D.service=Dhcp&displaytext=Network+offering-VR+services-8FM4XI&specifyVlan=False&serviceproviderlist%5B4%5D. >> provider=VirtualRouter&serviceproviderlist%5B1%5D.provider=VirtualRouter&availability=Optional&conservemode=True&servicecapabilitylist%5B1%5D. >> capabilitytype=SupportedSourceNatTypes&serviceproviderlist%5B3%5D.service=Dns&serviceproviderlist%5B5%5D.provider=VirtualRouter&response=json&serviceproviderlist%5B0%5D. >> provider=VirtualRouter&servicecapabilitylist%5B0%5D.capabilitytype=RedundantRouter&serviceproviderlist%5B8%5D.provider=VirtualRouter&serviceproviderlist%5B1%5D. >> service=Lb&servicecapabilitylist%5B0%5D.service=SourceNat&serviceproviderlist%5B4%5D. >> service=Firewall&supportedservices=Dhcp%2CDns%2CSourceNat%2CPortForwarding%2CVpn%2CFirewall%2CLb%2CUserData%2CStaticNat&traffictype=GUEST&servicecapabilitylist%5B1%5D. >> service=SourceNat&serviceproviderlist%5B6%5D.provider=VirtualRouter&serviceproviderlist%5B8%5D.service=StaticNat&serviceproviderlist%5B3%5D.provider=VirtualRouter&name=Network+ >> offering-VR+services-OLND5Q&guestiptype=Isolated&serviceproviderlist%5B7%5D.provider=VirtualRouter&servicecapabilitylist%5B1%5D. >> capabilityvalue=peraccount&serviceproviderlist%5B7%5D.service=SourceNat&serviceproviderlist%5B2%5D.service=PortForwarding&servicecapabilitylist%5B0%5D. >> capabilityvalue=true&serviceproviderlist%5B6%5D.service=Vpn&command=createNetworkOffering&signature=dFBPTQoc%2B%2B42%2FhDVyQQOFB87c7k%3D&serviceproviderlist%5B0%5D.service=UserData >> (Caused by : '') >> > > We actually don't use the submitCmdsAndWait to send the requests to > the mgmt server. We just send it through the apiclient and > cloudConnection.py takes over. I've seen the BadStatusLine issue with > httplib on our test systems too. It is pretty random. At first I > thought it was the throttling of the API but we don't enable that > setting. I'm still looking for why this happens ... and how to repro > it. > > >> These errors are intermittent. While investigating this problem I found this >> in marvin.cloudstackTestClient >> >> def submitCmdsAndWait(self, cmds, workers=1): >>'''FixME, httplib has issue if more than one thread submitted''' >>if self.asyncJobMgr is None: >>self.asyncJobMgr = asyncJobMgr.asyncJobMgr(self.apiClient, >> self.dbConnection) >>return self.asyncJobMgr.submitCmdsAndWait(cmds, workers) >> >> My theory is if the response from management server slow, multiple thread >> are submitted and we hit this issue. >> >> Please advise. >> >> Regards, >> Girish >> > > -- > Prasanna., > > > Powered by BigRock.com >
Re: Http connection failure in marvin
Lets track this issue here https://issues.apache.org/jira/browse/CLOUDSTACK-4846 Regards, Girish On 16-Oct-2013, at 11:30 AM, Prasanna Santhanam wrote: > httplib is used indirectly through requests. I'd try reproduce this > by throttling 1000s of requests through a single mgmt server. It is > intermittent because the mgmt server is probably loaded when you hit > it and possibly producing an invalid/empty response.
Http connection failure in marvin
Hello, Sometimes while running automation testcases tests just fail with following error: ConnectionError: HTTPConnectionPool(host='10.147.59.65', port=8080): Max retries exceeded with url: /client/api? apiKey=lcgWQ9XrjyIyPjsl7Y0BGI2udSRMs6S1w_42lWkwpCSfLWjkgoWvCakWwUCJ3TqfgMmuHWT4DXv5Lgoz-KCuSQ&egressdefaultpolicy=true&serviceproviderlist%5B2%5D. provider=VirtualRouter&serviceproviderlist%5B5%5D.service=Dhcp&displaytext=Network+offering-VR+services-8FM4XI&specifyVlan=False&serviceproviderlist%5B4%5D. provider=VirtualRouter&serviceproviderlist%5B1%5D.provider=VirtualRouter&availability=Optional&conservemode=True&servicecapabilitylist%5B1%5D. capabilitytype=SupportedSourceNatTypes&serviceproviderlist%5B3%5D.service=Dns&serviceproviderlist%5B5%5D.provider=VirtualRouter&response=json&serviceproviderlist%5B0%5D. provider=VirtualRouter&servicecapabilitylist%5B0%5D.capabilitytype=RedundantRouter&serviceproviderlist%5B8%5D.provider=VirtualRouter&serviceproviderlist%5B1%5D. service=Lb&servicecapabilitylist%5B0%5D.service=SourceNat&serviceproviderlist%5B4%5D. service=Firewall&supportedservices=Dhcp%2CDns%2CSourceNat%2CPortForwarding%2CVpn%2CFirewall%2CLb%2CUserData%2CStaticNat&traffictype=GUEST&servicecapabilitylist%5B1%5D. service=SourceNat&serviceproviderlist%5B6%5D.provider=VirtualRouter&serviceproviderlist%5B8%5D.service=StaticNat&serviceproviderlist%5B3%5D.provider=VirtualRouter&name=Network+ offering-VR+services-OLND5Q&guestiptype=Isolated&serviceproviderlist%5B7%5D.provider=VirtualRouter&servicecapabilitylist%5B1%5D. capabilityvalue=peraccount&serviceproviderlist%5B7%5D.service=SourceNat&serviceproviderlist%5B2%5D.service=PortForwarding&servicecapabilitylist%5B0%5D. capabilityvalue=true&serviceproviderlist%5B6%5D.service=Vpn&command=createNetworkOffering&signature=dFBPTQoc%2B%2B42%2FhDVyQQOFB87c7k%3D&serviceproviderlist%5B0%5D.service=UserData (Caused by : '') These errors are intermittent. While investigating this problem I found this in marvin.cloudstackTestClient def submitCmdsAndWait(self, cmds, workers=1): '''FixME, httplib has issue if more than one thread submitted''' if self.asyncJobMgr is None: self.asyncJobMgr = asyncJobMgr.asyncJobMgr(self.apiClient, self.dbConnection) return self.asyncJobMgr.submitCmdsAndWait(cmds, workers) My theory is if the response from management server slow, multiple thread are submitted and we hit this issue. Please advise. Regards, Girish
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/ --- (Updated Oct. 16, 2013, 2:27 p.m.) Review request for cloudstack, Harikrishna Patnala and venkata swamy babu budumuru. Changes --- Updated the patches as per the review. Bugs: CLOUDSTACK-4637 Repository: cloudstack-git Description --- Add logic to wait for router to boot. Diffs (updated) - test/integration/component/test_egress_fw_rules.py 5c18f9c Diff: https://reviews.apache.org/r/14469/diff/ Testing (updated) --- 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 14334: CLOUDSTACK 4705: Fixed domain memory limits test cases
> On Oct. 8, 2013, 11:14 a.m., abhinav roy wrote: > > Ship It! Can someone commit this patch. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14334/#review26770 --- On Sept. 25, 2013, 11:06 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14334/ > --- > > (Updated Sept. 25, 2013, 11:06 a.m.) > > > Review request for cloudstack, sailaja mada and Prasanna Santhanam. > > > Repository: cloudstack-git > > > Description > --- > > Fixed CLOUDSTACK 4705: > Removed attribute error and fixed indentation issues. > > Added update_resource_count method to update the resource count after > upgrading and downgrading the service offering so as to get latest count. > Issue was found that it was showing old resource count without calling this > API. > > > Diffs > - > > test/integration/component/memory_limits/test_domain_limits.py 479ec0b > > Diff: https://reviews.apache.org/r/14334/diff/ > > > Testing > --- > > > Thanks, > > Gaurav Aradhye > >
Re: Http connection failure in marvin
Thanks Santhosh for the pointers. I will investigate on these lines. Regards, Girish On 16-Oct-2013, at 3:02 PM, Santhosh Edukulla wrote: > Girish, > > Thanks for the bug. Few notes below. > > 1/ Can you please add the server GET\POST calls with params received at the > server information to the bug? This will help to know for which GET/POST call > this issue has appeared? > > > 2/ Under tools/marvin/marvin/cloudstackConnection.py, there is a member > function "request" under cloudConnection class. If this exception is > appearing quiet a good number of times. Can you please add this specific > exception( BadStatusLine ) to be caught and collect few specific information > for request sent,response recieved when that exception is caught in your next > run? The total url with args and body to be dumped etc in a file? > > 3/ We are using requests library to make http calls under marvin, it seems > there is a way to enable debug information for this library, check the below > link. Please enable the debug information for this library and run the tests > again to see by catching the complete request payload when this specific > exception is raised. > > http://docs.python-requests.org/en/master/api/#api-changes > > # these two lines enable debugging at httplib level > (requests->urllib3->httplib) > # you will see the REQUEST, including HEADERS and DATA, and RESPONSE with > HEADERS but without DATA. > # the only thing missing will be the response.body which is not logged. > import httplib > httplib.HTTPConnection.debuglevel = 1 > > > 4/ One of the link suggests a trailing new line character for the request as > the cause for this issue. Adding complete server calls and debug information > will help to debug more i believe? > > http://stackoverflow.com/questions/1767934/why-am-i-getting-this-error-in-python-httplib > > Check above and you can get more information for this issue to delve further. > > > Thanks! > Santhosh > > From: Girish Shilamkar [gir...@clogeny.com] > Sent: Wednesday, October 16, 2013 3:01 AM > To: dev@cloudstack.apache.org > Subject: Re: Http connection failure in marvin > > Lets track this issue here > https://issues.apache.org/jira/browse/CLOUDSTACK-4846 > > Regards, > Girish > > On 16-Oct-2013, at 11:30 AM, Prasanna Santhanam wrote: > >> httplib is used indirectly through requests. I'd try reproduce this >> by throttling 1000s of requests through a single mgmt server. It is >> intermittent because the mgmt server is probably loaded when you hit >> it and possibly producing an invalid/empty response. >
Review Request 14872: CLOUDSTACK-4934: Rename Limit resources tests so that they have unique names
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14872/ --- Review request for cloudstack and Rayees Namathponnan. Bugs: CLOUDSTACK-4934 https://issues.apache.org/jira/browse/CLOUDSTACK-4934 Repository: cloudstack-git Description --- Patch for master branch. Diffs - test/integration/component/cpu_limits/test_cpu_limits.py d721a45 test/integration/component/cpu_limits/test_domain_limits.py 4e8fc6d test/integration/component/cpu_limits/test_maximum_limits.py 9161cee test/integration/component/cpu_limits/test_project_limits.py 63d1a98 test/integration/component/memory_limits/test_domain_limits.py d87db84 test/integration/component/memory_limits/test_maximum_limits.py b1ebbb4 test/integration/component/memory_limits/test_memory_limits.py 18eab4c test/integration/component/memory_limits/test_project_limits.py 1c0ed92 test/integration/component/test_cpu_domain_limits.py PRE-CREATION test/integration/component/test_cpu_limits.py PRE-CREATION test/integration/component/test_cpu_max_limits.py PRE-CREATION test/integration/component/test_cpu_project_limits.py PRE-CREATION test/integration/component/test_memory_limits.py PRE-CREATION test/integration/component/test_mm_domain_limits.py PRE-CREATION test/integration/component/test_mm_max_limits.py PRE-CREATION test/integration/component/test_mm_project_limits.py PRE-CREATION Diff: https://reviews.apache.org/r/14872/diff/ Testing --- Thanks, Girish Shilamkar
Review Request 14873: CLOUDSTACK-4934: Rename Limit resources tests so that they have unique names
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14873/ --- Review request for cloudstack and Rayees Namathponnan. Bugs: CLOUDSTACK-4934 https://issues.apache.org/jira/browse/CLOUDSTACK-4934 Repository: cloudstack-git Description --- Patch for 4.2 branch Diffs - test/integration/component/cpu_limits/test_cpu_limits.py d721a45 test/integration/component/cpu_limits/test_domain_limits.py 4e8fc6d test/integration/component/cpu_limits/test_maximum_limits.py 9161cee test/integration/component/cpu_limits/test_project_limits.py 63d1a98 test/integration/component/memory_limits/test_domain_limits.py d87db84 test/integration/component/memory_limits/test_maximum_limits.py b1ebbb4 test/integration/component/memory_limits/test_memory_limits.py 18eab4c test/integration/component/memory_limits/test_project_limits.py 1c0ed92 test/integration/component/test_cpu_domain_limits.py PRE-CREATION test/integration/component/test_cpu_limits.py 814e4b0 test/integration/component/test_cpu_max_limits.py PRE-CREATION test/integration/component/test_cpu_project_limits.py PRE-CREATION test/integration/component/test_mm_domain_limits.py PRE-CREATION test/integration/component/test_mm_limits.py PRE-CREATION test/integration/component/test_mm_max_limits.py PRE-CREATION test/integration/component/test_mm_project_limits.py PRE-CREATION Diff: https://reviews.apache.org/r/14873/diff/ Testing --- Thanks, Girish Shilamkar
Re: Review Request 14319: CLOUDSTACK 2238: Automation - Non Contiguous VLAN Ranges
On Oct. 23, 2013, 9:08 a.m., Gaurav Aradhye wrote: > > The naming of the tests should be improved. test_01/02/03 doesn't tell much > > about the test. Also is the ordering strictly required? Can I reorder the > > tests and still expect the tests to pass? If not, we should remove the 01 , > > 02 , 03 in the tests. > > Gaurav Aradhye wrote: > Yes the tests can be reordered and run successfully. I will change the > test names. The only reason to keep such test names was to avoid long test > names which tell the same thing which is written in the comments (Steps and > validation steps), 01,02,03 does not stand for any ordering. > > Prasanna Santhanam wrote: > A meaningful name still makes sense for the tests as the Marvin > TestRunner shows the first line in your docstring and if that's not available > the name of the test itself which will look like test_01. The report is > easier to understand with names. That's my only complaint. The problem with earlier test naming was that neither the name could indicate purpose of the test, given its complexity nor name was concise enough to be called out. With new names it is at least easy to refer tests "non_contiguous_vlan test_03" instead of some test_name_too_long_to_use_but_to_short_to_describe_test. And the tests will have the description of what it does. Secondly, we use testname to construct account name and the db cannot handle account name more that 100 chars. I have seen at least one such defect. The numbering does not indicate sequential order for execution. - Girish --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14319/#review27372 --- On Oct. 23, 2013, 9:01 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14319/ > --- > > (Updated Oct. 23, 2013, 9:01 a.m.) > > > Review request for cloudstack, bharat kumar and sanjeev n. > > > Repository: cloudstack-git > > > Description > --- > > Adding Automation test cases for feature - Non Contiguous VLAN ranges > CLOUDSTACk 2238. > > > Diffs > - > > test/integration/component/test_non_contiguous_vlan.py PRE-CREATION > > Diff: https://reviews.apache.org/r/14319/diff/ > > > Testing > --- > > Tested locally on XenServer Setup > > Log: > > test_01 (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok > test_02 (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok > test_03 (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok > test_04 (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok > test_05 (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok > > -- > Ran 5 tests in 22.387s > > OK > > > Thanks, > > Gaurav Aradhye > >
Re: [ANNOUNCE] New Committer: Shilamkar, Girish
Thank you all ! Regards, Girish On 24-Oct-2013, at 12:45 AM, Rayees Namathponnan wrote: > Congrats Girsih > > -Original Message- > From: Ahmad Emneina [mailto:aemne...@gmail.com] > Sent: Wednesday, October 23, 2013 10:34 AM > To: dev@cloudstack.apache.org > Subject: Re: [ANNOUNCE] New Committer: Shilamkar, Girish > > Nice work Girish! > > > On Wed, Oct 23, 2013 at 9:59 AM, Sangeetha Hariharan < > sangeetha.hariha...@citrix.com> wrote: > >> 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: Review Request 14459: CLOUDSTACK-2243: Add automation tests for VMs base image update faclity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14459/#review27595 --- Ship it! Ship It! - Girish Shilamkar On Oct. 28, 2013, 6:02 a.m., Ashutosh Kelkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14459/ > --- > > (Updated Oct. 28, 2013, 6:02 a.m.) > > > Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. > > > Bugs: CLOUDSTACK-2243 > https://issues.apache.org/jira/browse/CLOUDSTACK-2243 > > > Repository: cloudstack-git > > > Description > --- > > Added new test class to test Base Image Updation Facility. > > > Diffs > - > > test/integration/component/test_base_image_updation.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py 4f15137 > > Diff: https://reviews.apache.org/r/14459/diff/ > > > Testing > --- > > Tested locally on KVM advanced setup: > > Log: > > ==> result.log <== > test_01_deploy_instance_with_is_volatile_offering > (test_base_image_updation.TestBaseImageUpdate) > Test deploy an instance with service offerings with IsVolatile set. ... ok > test_02_reboot_instance_with_is_volatile_offering > (test_base_image_updation.TestBaseImageUpdate) > Test rebooting instances created with isVolatile service offerings ... > ==> client.log <== > 2013-10-09 20:22:30,659 - DEBUG - > test_02_reboot_instance_with_is_volatile_offering > (test_base_image_updation.TestBaseImageUpdate) - Checking root > th isVolatile=True > 2013-10-09 20:22:30,695 - DEBUG - > test_02_reboot_instance_with_is_volatile_offering > (test_base_image_updation.TestBaseImageUpdate) - Checking root > th isVolatile=False > > ==> result.log <== > ok > test_03_restore_vm_with_new_template > (test_base_image_updation.TestBaseImageUpdate) > Test restoring a vm with different template than the one it was created with > ... > ==> client.log <== > 2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template > (test_base_image_updation.TestBaseImageUpdate) - Registered a template of fo > ith ID: 5a9190a9-8a59-487f-b90f-4a76a0f509a0 > 2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template > (test_base_image_updation.TestBaseImageUpdate) - Waiting for download of tem > : 5a9190a9-8a59-487f-b90f-4a76a0f509a0 > 2013-10-09 20:38:25,367 - DEBUG - test_03_restore_vm_with_new_template > (test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM > le=True > 2013-10-09 20:38:25,386 - DEBUG - test_03_restore_vm_with_new_template > (test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM > le=False > 2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules > (test_base_image_updation.TestBaseImageUpdate) - Creating recurring snapshot > po > disk on vm created with IsVolatile=True > 2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules > (test_base_image_updation.TestBaseImageUpdate) - Snapshot Policy - Type : > HOURL > inute : 53 > 2013-10-09 20:38:30,982 - DEBUG - test_04_reoccuring_snapshot_rules > (test_base_image_updation.TestBaseImageUpdate) - Sleeping for 25 minutes till > t > snapshoted > > ==> result.log <== > ok > test_04_reoccuring_snapshot_rules > (test_base_image_updation.TestBaseImageUpdate) ... > ==> client.log <== > 2013-10-09 21:11:51,780 - DEBUG - test_04_reoccuring_snapshot_rules > (test_base_image_updation.TestBaseImageUpdate) - Checking whether root disk of > atile=True was destroyed > 2013-10-09 21:11:51,827 - DEBUG - test_04_reoccuring_snapshot_rules > (test_base_image_updation.TestBaseImageUpdate) - Checking whether snapshot > rule > isVolatile=True was destroyed > > ==> result.log <== > ok > > -- > Ran 4 tests in 3534.241s > > OK > > > Thanks, > > Ashutosh Kelkar > >
