[[PageOutline]] [wiki:GEC21Agenda/OEDL <-- Back to Main Tutorial Page] | [wiki:GEC21Agenda/OEDL/Experiment2 Next to Experiment 2 -->] {{{ #!html
This first part shows how to design, execute, and view the results of an experiment, which dynamically reacts to a user-defined event.
This experiment demonstrate OEDL’s capability to allow user to define events which will trigger based on the state of the used resources. In other words, if one or more resources reaches a specific state, the event will trigger and some user-defined tasks will be executed.
In this experiment:
For specific help on using LabWiki, please refer to the LabWiki introduction page
The OEDL experiment description
Walk-through the OEDL experiment description
First, a reminder that all details on OEDL are available in the OEDL reference page
loadOEDL (line 12). This command is used to include in your OEDL experiment other external OEDL scripts. In this example, we are loading the definition of a ping application, which has been instrumented with OML
defProperty (line 14–18). This command is used to define experiment properties (aka variables), you can set the values of these properties as parameters for each experiment trials, and access them throughout the entire experiment run. In this example, we are defining 5 properties, to hold the names of each of the resources that we will use and the target for the ping application.
Some internal variables (line 21–29). These are classic simple Ruby commands that allow us put all our resource in a single list, then split that list into one holding the ‘initial’ resources, and one holding the ‘backup’ resources. As opposed to the above defProperty variables, these internal variables cannot be set at the start of each experiment trial (without having to change the content of the OEDL script itself)
defGroup (line 32–41). This command is used to define a group of resources which we will use in this experiment. A group may contain many resources or any other group, and a resource may be included in many groups. This commands may also be used to associate a set of configurations and applications to all resources in a group. In this example, we first define 4 groups (e.g. ‘Worker_X’), each with only one resource, then we are associating an instrumented ping to the unique resource in each group. This association is done using the addApplication. Furthermore, we also define a final group (‘Initial_Worker’), which will contain the ‘Worker’ groups with the initial resources.
onEvent (line 55–61). This command declares the set of actions to perform when a specific event is triggered. In this example, the event is our previously defined “APP_EXITED”. The actions to perform in this case is to select a backup resource and start its ping application. There is another onEvent declaration further (line 68–74), for the event “APP_UP_AND_INSTALLED”, i.e. when all resources are ready to receive commands and all applications associated to them are installed. When this event triggers, we start the ping application on the resources within the ‘Initial_Worker’ group, then after 60 seconds we stop all applications and terminate the experiment trial.
defGraph (line 76–83). This commands defines the graphs that will be displayed while the experiment trial is running. In this example, we define 1 graph showing the RTT values from the ping applications against time for each resources in our experiment. This graph will be drawn using measurements enabled in the previous defGroup blocks.
You may interact to with these graphs, e.g. tick or un-tick the legend’s keys to display only results from the first or/and second resource, hover the pointer above a graph point to display the underlying data point, drag-and-drop the graph via its icon to the “Plan” panel as described in the LabWiki introduction page
The complete data set holding the measurements collected from this experiment is stored in an SQL database. You can retrieve a copy of that database by clicking on the ‘Database Dump’ buttom in the ‘Execute’ panel. The format of that copy is depends on your LabWiki’s deployment configuration. It could be an iRODS dump, a Zipped archive of CSV files, a SQLite3 dump or a PostgreSQL dump. By default, it is a PostgreSQL dump.