> On Aug. 20, 2013, 6:30 a.m., venkata swamy babu budumuru wrote: > > test/integration/component/test_netscaler_lb.py, line 166 > > <https://reviews.apache.org/r/13680/diff/1/?file=342459#file342459line166> > > > > Since you have multiple test suites trying to add the same netscaler > > device, it will be good to keep this whole creation stuff in try block so > > that even if something fails then you will have your tearDown called. > > > > something like I mentioned here : > > > > try: > > > > add_netscaler() > > NetworkOffering.create() > > ServiceOffering.create() > > > > except: > > > > call tearDownClass() > > > > If we do it in the above way then if something goes wrong in network > > offering creation then our except block will still call the tearDown for > > removing netscaler device so that your rest of test suites will not fail > > during netscaler device addition.
Ok. Will do this for all tests > On Aug. 20, 2013, 6:30 a.m., venkata swamy babu budumuru wrote: > > tools/marvin/marvin/integration/lib/common.py, line 62 > > <https://reviews.apache.org/r/13680/diff/1/?file=342462#file342462line62> > > > > IMO, we don't have to go for an additional library call for > > add_netscaler rather we can rely just on Netscaler.add in base.py. few > > reasons for saying this is as mentioned below. > > > > 1. Usually the automation environment is prepared out of a .cfg file > > where we can add the following to make a provider configured and enabled by > > default using something like below > > > > "providers": [ > > > > { "broadcastdomainrange": "ZONE", > > > > "name": "Netscaler" > > } > > ] > > > > > > The reason why I thought we need a separate library is because, adding NS involves the following: finding the physical network id, adding NS, finding the NS service providers, and enabling it if not enabled. In all, this is about 25 odd lines of code in 20 different set up classes across all tests. So I added a library. Regarding automation pre-configured environment which may include NS device as well, Here's the reason why I chose to add NS device in each test: Currently the tests assume that the NS device added by the test is the only one in the environment. We assert tests by doing an ssh into NS and testing if services are present. Now, if there are devices added externally unknown to the test or if there are more devices than those assumed by the test script, then the test potentially could fail looking at the wrong NS. That's the reason for adding NS independently in each test. Please let me know if any comments. - Sowmya ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13680/#review25340 ----------------------------------------------------------- On Aug. 20, 2013, 6:18 a.m., Sowmya Krishnan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13680/ > ----------------------------------------------------------- > > (Updated Aug. 20, 2013, 6:18 a.m.) > > > Review request for cloudstack, venkata swamy babu budumuru and Prasanna > Santhanam. > > > Bugs: CLOUDSTACK-3927 and CLOUDSTACK-3928 > > > Repository: cloudstack-git > > > Description > ------- > > Fix to add NS device in setupClass and remove in tearDown > Added a common method to perform these in common.add_netscaler() > Also fixes few account object issues in netscaler_configs. > > Patch will help in keeping each test suite independent. Otherwise we cannot > identify which NS an LB rule will be deployed in if there's more than one NS > device. > > > Diffs > ----- > > test/integration/component/test_netscaler_configs.py bcea254 > test/integration/component/test_netscaler_lb.py 3942f94 > test/integration/component/test_netscaler_lb_algo.py 477bd69 > test/integration/component/test_netscaler_lb_sticky.py 1edfd7b > tools/marvin/marvin/integration/lib/common.py 4f5acef > > Diff: https://reviews.apache.org/r/13680/diff/ > > > Testing > ------- > > Tested locallly > > > Thanks, > > Sowmya Krishnan > >
