Re: [Avocado-devel] Using Avocado as a system level test

[Lukáš Doktor]

Dne 30.9.2016 v 19:40 Michael Mohr napsal(a):

Good morning;



I’m attempting to implement a system level test framework using
Avocado.  At the moment, I’m trying to determine whether it is possible
to run multiple instances of one or more test modules in parallel within
the current Avocado framework.  A simple example would be running “dd”
on a collection of drives attached to an HBA.  Certainly it is possible
to just enumerate attached drives using e.g. python-parted and loop over
them all, starting process.SubProcess instances on all of them.  But
this example is still too simple; what if, for example, it is desirable
to run fio or badblocks on some of them instead?  I’d prefer to
implement separate test modules to support different drive stressors so
that the implementation of each stressor is clean but the calling
interface is unified.  Further, what if it is desirable to run multiple
instances of one or more stressor test modules on a single rotational
drive (to force the drive heads to move around randomly)?

I'm not sure I 100% understand the point, but I had done some tests with background stressers and one way is to create several tests and spawn them in parallel (planned, as dmonakhov pointed out), or you can develop a library of stresser classes and start/stop them within the tests:

```
class DiskStress(object):
    ...
    def start(self):
        self.process = process.get_sub_process_klass(self.cmd)
        self.process.start()
    def stop(self):
        os.kill(self.process.get_pid())

class MyTest(avocado.Test):
    def setUp(self):
        self.stress = []
        for disk in params.get("disks"):
            self.stress.append(DiskStress(disk))
    def tearDown(self):
        for stress in self.stress:
            stress.stop()
```

The DiskStress should be implemented in `avocado.utils` along with other useful tools like lvm_utils... Anyway for more complex stressers the https://trello.com/c/xNeR2slj/255-support-running-tests-in-parallel or JobAPI would be better.

Regards,
Lukáš

PS: Your example was actually listed in one of mine RFCs about the tests in parallel, but we're waiting for a counter proposal, which has lower priority than the JopAPI for now. The JobAPI should be more generic way of arranging tests, so it should supersede the running tests in parallel (or at least overlap a bit). We are getting there, but it might still take some time.

The above just addresses drive stress.  The CPUs and memory should be
stressed at the same time, and would require different test modules.  If
there is any guidance on this usage of Avocado within the documentation,
I’ve not yet seen it.



Michael Mohr

Office: 510-668-3527

Mobile: 510-449-9331

Hyve Solutions

hyve-solutions

signature.asc
Description: OpenPGP digital signature