Decouple workload generation from C++ code about crashmonkey HOT 18 CLOSED

Are we making any assumptions as to what device the user workload will be run on? Should we assume it's run on an arbitrary block device? Or should we assume it's run on our custom RAM block device? Running on an arbitrary one is possible, we'll just have to make sure we have a snapshot of the actual disk it's running on before we allow the workload to run.

from crashmonkey.

from crashmonkey.

Are we thinking of any certain way to do this in particular? How integrated should it be with the rest of CrashMonkey? Currently the device wrapper exposes ioctls to start/stop logging as well as another set of ioctls to retrieve logged information. Do you have any ideas on what sort of interface we should present users if they don't want to use the C++ harness code?

If users decide to use the start/stop logging feature, should it automatically start CrashMonkey tests when they stop logging or should more user interaction be required to start testing?

from crashmonkey.

from crashmonkey.

I was thinking about this and came up with two ideias:

1. allow the user to specify the the programs/scripts that would be executed in each step, something like: ./harness -{...} --setup=./setup.sh --run=./run.sh --test=./test.sh
2. split the harness program in four, and the workflow will like:

• ./harness prepare {...}
• ./setup.sh
• ./harness startLogging {...}
• ./run.sh
• ./harness stopLogging {...}
• ./harness test {...} --test=./test.sh

I hope this makes sense.

from crashmonkey.

from crashmonkey.

I also had a similar idea to what @domingues said. In harness prepare we do some simple stuff like shorten the writeback delay, insert kernel modules, drop caches (for now, we can remove this bit if we want), load up test classes etc. Mostly it is just organizational stuff to make sure the rest of the harness runs smoothly and (hopefully) consistently.

from crashmonkey.

I think getting this working is currently Priority #1. With this, we should be able to test crashes in the middle of journal recovery.

from crashmonkey.

@vijay03 do we have any idea how user data consistency tests should be handled if CrashMonkey is run in the background for the workload? Should we still constrain user consistency tests to use the interface in CrashMonkey?

from crashmonkey.

Yup, we still want the user to use Checkpoints (through a shell script) for user consistency tests

from crashmonkey.

Will the CrashMonkey automatically start the tests by running the test defined in the user provided test case C++ file or will CrashMonkey provide some other interface to allow users more flexibility similar to how we are providing more flexibility for workloads?

from crashmonkey.

Flexibility during testing is not a priority right now, so one command to start off testing will be enough for now. After the profiling step, it should require a specific command to start testing. We might need to insert additional steps between profiling and testing, so we want the two to be separate.

from crashmonkey.

@ashmrtn I don't know if you already have some code to do the communication between the harness and the "tests", to proceed with the issue #12 I have done this 283374b. Feel free to take a look.

from crashmonkey.

@domingues I have created similar code and was thinking how best to package it as it will be used in several places it seems. For now, continue with what you have and we can refactor once we have things working.

You should also look into ntohl() and htonl() as we should avoid making assumptions about the endianness of the system.

from crashmonkey.

@ashmrtn could you update the README about running CrashMonkey in the background?

from crashmonkey.

Sure thing!

from crashmonkey.

@vijay03 can I just commit README updates directly to master or would you like to PR them in?

from crashmonkey.

You commit them directly. I'll close this issue.

from crashmonkey.