Diagnostics

• It can be used to verify the configuration of a Bourreau server, including testing the full cycle of setting up a job, launching it, and post processing it;
• It can be used by system programmers to try (and validate) the special form input fields helpers that CBRAIN provides for writing CbrainTasks;
• It can ask the Bourreau side to perform some connectivity tests with the Data Providers;
• It can be used by system programmers to trigger some task lifecycle events on the Portal side during task creation and edit, in order to test the Rails tasks_controller.

Parameters

Input Files:

This is an arbitrary list of one or more files that were selected by the user; this task will simply synchronize them, and either run the UNIX du command when the files are directories, or wc if they are simple files. This will test that the Bourreau server is actually capable of running a bash script as a job on the local cluster.

Do not actually submit job script on cluster:

When set, no job will be submitted on the cluster; the rest of the task's life cycle will be performed normally, however (Setup and Post Processing for instance).

Life Cycle Table

Here you can selectively trigger several events in the life cycle of this task while being processed on the Bourreau side. These events are mostly useful for system programmers who want to test the CBRAIN framework's ability to handle them. There are three main stages represented in this table:

• Setup: when Ruby code for the task's setup() method is invoked;
• Cluster: when the bash script is executed on the cluster;
• PostProcess: when Ruby code for the task's post_process() method is invoked.

In each case, it is possible to force the task to wait for a certain number of seconds, and then to crash. In the case of Ruby code, crashing will mean explicitly raising a Ruby exception. In the case of on Cluster, it means the post_process() method will pretend that the bash script has not performed successfully and will return 'false'.

For each of these stages, it is possible to enable the six callback methods for the restart capabilities API or error recovery API, and to make them wait a certain number of seconds too.

Crashes will reset to false after they are first triggered

It's possible to make the synthetic crashes configured in the previous table happen only once. This can test a scenario where an error occurs, then recovery is attempted and then everything returns to normal.

Check Data Providers Access

Each Data Provider selected in this table will be polled during the task's Setup stage. A report of their availability will be put inside the task's log.

Input Fields Validation Tests

These are used to test the validation code associated with input fields of different type. These input fields are generated by the CBRAIN framework's CbrainTaskFormBuilder helper methods, and the Diagnostics task has, built-in, a set of dummy rule for validating them. Entering incorrect values will make sure they are highlighted properly. This is mostly used to verify the framework itself, not the Diagnostic task.

Interface after_form() Lifecycle Test

This section controls the behavior of the diagnostics task's after_form() method. It can be made to raise exception, or return a particular message string, and/or store that string as a field error associated with the text input box.

Erase report after it is created

The diagnostics tasks usually create a new file within CBRAIN containing the text of its bash job's output. If it's not really needed to be kept, it can be made to be automatically deleted after creation (this will still test that the diagnostics task is able to create files on the Data Provider chosen for its output, but will not clutter it with the report itself).

Stress-Testing

Warning: can be costly This options allow the operator to launch a great quantity of the identical copies of the diagnostics task.

See also