----- "supriya kannery" <supriyak@xxxxxxxxxx> wrote:
> Uri Lublin wrote:
> > supriya kannery wrote:
> >> A patch for iterating over VM reboot
> >>
> >
> > I think adding iterations capability belongs to the infrastructure,
>
> > not the test itself. Implement it once in the infrastructure,
> instead
> > of once per test.
> > Also I think autotest has such a capability (adding iteration=n to
> > job.run_test parameters).
> >
> In the older version of kvm_runtest (kvm_runtest_old), the iteration
> parameter can be added to the corresponding job.runtest() of each test
>
> type (boot, reboot, migration).Different Class and execute function
> are
> defined for each test type in old runtest infrastructure which gives
> the
> flexibility of providing independent iteration values. But in the
> current infrastructure, I am not sure how we can apply that way to
> iterate each test type. My guess is, defining an iteration parameter
> under corresponding test type variant in the kvm_test.cfg file is
> one
> of the ways. Pls let me know if I overlooked anything here.
There are two quick ways I can think of.
In both cases, the user needs to define something like "iterations = 4" in the config file, where desired.
Different tests can have different iteration values, depending on where the parameter is set.
1. Read the 'iterations' parameter in the control file, and pass its value as the 'iterations' parameter to job.run_test(), e.g.
iterations = int(dict.get("iterations", "1"))
current_status = job.run_test("kvm_runtest_new", params=dict, tag=dict.get("shortname"), iterations=iterations)
Hopefully the iteration number will be appended to the test tag (e.g. Fedora.8.32.reboot.1, Fedora.8.32.reboot.2...).
- or -
2. Call job.run_test() as many times as desired (with a for loop), and append the iteration number to the test tag yourself, e.g.
iterations = int(dict.get("iterations", "1"))
for i in range(iterations):
current_status = job.run_test("kvm_runtest_new", params=dict, tag=dict.get("shortname")+"."+str(i+1))
if not current_status:
break
While the first option is slightly shorter, I think the second one is safer (more predictable).
Migration is a special case because it currently comprises two tests (.1 and .2). Right now the only way to run multiple paired migrations is to add another 'variants' block inside the migration test block, e.g.
variants:
- 1:
- 2:
- 3:
Michael
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
