wiki:GEC22Agenda/LabWiki/ModuleA/Execute

Version 2 (modified by eswer18@gmail.com, 10 years ago) (diff)

--

Module A Execute Experiment

3. Instrument your Application using LabWiki

In this part of Module A you will learn how you can use LabWiki to execute an experiment on the slice you reserved in the previous step.

3.1 Design and Execute measurement in LabWiki

3.1.1. The "Plan" Window

To get started point your browser to http://labwiki.casa.umass.edu. Labwiki has three major windows. We will focus on the leftmost window first. This is the "Planning" window in which you document your experiment. (This is somewhat the equivalent of an electronic lab journal.) Documents are written in Markdown.

At the top of that window is a text field which you can use to search for existing MD scripts. Type "GEC22-learningswitch" in the field and then select "GEC22-learningswitch.md" from the list of files that are offered. This document has some information on the experiment that will be performed in Module A of the tutorial.

3.1.2 The "Prepare" Window

The "Prepare" (middle) window allows you to define your experiment through and OMF experiment script specified in OMF Experiment Description Language (OEDL).

At the top of that window is a text field which you can use to search for existing OEDL scripts. Type "GEC22" in the field and then select "GEC22-learningswitch.oedl" from the list of files that are offered. This shows the experiment script in the field below.

For reference, we show the experiment script here:

defProperty('source1', "nodea-learningswitch", "ID of a resource")
defProperty('source2', "switch-learningswitch", "ID of a resource")


defProperty('sinkaddr12', '192.168.1.7', "Ping destination address")
defProperty('sinkaddr13', '192.168.1.8', "Ping destination address")

defProperty('sinkaddr21', '192.168.1.9', "Ping destination address")
defProperty('sinkaddr11', '192.168.1.6', "Ping destination address")
peak_list = []

defApplication('ping') do |app|
  app.description = 'Simple Definition for the ping-oml2 application'
  # Define the path to the binary executable for this application
  app.binary_path = '/usr/local/bin/ping-oml2'
  # Define the configurable parameters for this application
  # For example if target is set to foo.com and count is set to 2, then the 
  # application will be started with the command line:
  # /usr/bin/ping-oml2 -a foo.com -c 2
  app.defProperty('target', 'Address to ping', '-a', {:type => :string})
  app.defProperty('count', 'Number of times to ping', '-c', {:type => :integer})
  # Define the OML2 measurement point that this application provides.
  # Here we have only one measurement point (MP) named 'ping'. Each measurement
  # sample from this MP will be composed of a 4-tuples (addr,ttl,rtt,rtt_unit)
  app.defMeasurement('ping') do |m|
    m.defMetric('remote',:string)
    m.defMetric('ttl',:uint32)
    m.defMetric('rtt',:double)
    m.defMetric('rtt_unit',:string)
  end
end

defApplication('trema') do |app|
  app.description = 'This app runs trema from command line'
  app.binary_path = '/bin/sh /root/ovs-setup2.sh'
end
defGroup('Source2', property.source2) do |node|
  node.addApplication("trema")
end
defGroup('Source1', property.source1) do |node|
  node.addApplication("ping") do |app|
    app.setProperty('target', property.sinkaddr12)
    app.setProperty('count', 30)
    #app.setProperty('interval', 1)
    app.measure('ping', :samples => 1)
  end
  node.addApplication("ping") do |app|
    app.setProperty('target', property.sinkaddr13)
    app.setProperty('count', 30)
    #app.setProperty('interval', 1)
    app.measure('ping', :samples => 1)
  end
   node.addApplication("ping") do |app|
    app.setProperty('target', property.sinkaddr21)
    app.setProperty('count', 30)
    #app.setProperty('interval', 1)
    app.measure('ping', :samples => 1)
  end
end

defGroup('Source3', property.source1) do |node|
  node.addApplication("ping") do |app|
    app.setProperty('target', property.sinkaddr11)
    app.setProperty('count', 30)
    #app.setProperty('interval', 1)
    app.measure('ping', :samples => 1)
  end
end

defEvent(:MY_EVENT, every: 0.5) do
# Query for some measurements...
  # returns an array where each element is a hash representing a row from the DB
  query = ms('ping').select { [ :remote] }
  data = defQuery(query)
  # Alternatively the above line could also be:
  # data = defQuery('select oml_ts_client, value from signalgen_sin')
  #
  # Also if you want to rename 'oml_ts_client' to 'ts'
  # query = ms('sin').select { [ oml_ts_client.as(:ts), :value ] } 
  # data = defQuery('select oml_ts_client as ts, value from signalgen_sin')

  triggered = false
  if !data.nil? && !(last_row = data.pop).nil? # Make sure we have some data
    next if peak_list.include?(last_row[:remote]) # Do nothing if we have seen this sample before
    if !peak_list.include?(last_row[:remote])
      peak_list << last_row[:remote] # record that sample, so we dont trigger on it again
    end
    if peak_list.include?('192.168.1.9')&&peak_list.include?('192.168.1.7')&&peak_list.include?('192.168.1.8')
      
      triggered = true
    end
  end
  triggered
end
onEvent :MY_EVENT do
  #group('switch').exec("ping www.google.com")
  group('Source3').startApplications
end

onEvent(:ALL_UP_AND_INSTALLED) do |event|
  info "Starting the ping"
  after 1 do
    group('Source2').startApplications
  end
  after 30 do
    group('Source1').startApplications
  end
  after 80 do
    info "Stopping the ping"
    allGroups.stopApplications
    Experiment.done
  end
end

defGraph 'RTT' do |g|
  g.ms('ping').select(:oml_seq, :remote, :rtt) 
  g.caption "RTT of received packets."
  g.type 'line_chart3'
  g.mapping :x_axis => :oml_seq, :y_axis => :rtt, :group_by => :remote
  g.xaxis :legend => 'oml_seq'
  g.yaxis :legend => 'rtt', :ticks => {:format => 's'}
end


3.1.3 Start your application from LabWiki

To start your experiment, simply drag the icon that is to the left of the file name (see figure below) from the middle (Prepare) to the right (Execute) window. That will automatically fill out the experiment relevant information in this window

Explanation of the fields in the Execute window:

  • name: In this field you specify the name of your experiment.
  • project: This pull-down menu list all the projects you are currently a member of. Select the project that contains the slice you want to run your experiment on.
  • experiment context: With the context you can specify a certain set of experiments. E.g., a series of experiments you run under a certain set of startup parameters. This field is not mandatory and only necessary if you would like to save your experiment data to view later.
  • slice: This pull down menu lists all slice that have been created under "project". Select the slice you would like to run your experiment on.

*Change source1 and source2 fields to include your slice name similar to nodea-<slicename>

Then, start the actual experiment by clicking on the "Start Experiment" button.

http://groups.geni.net/geni/raw-attachment/wiki/GEC20Agenda/LabWiki/ModuleA/Execute/LW-execute.png

3.1.4 During experiment execution

After pressing the "Start" button, the Execute window will change and start showing status information about your experiment. The figure below gives an example for the Execute window during experiment execution.

http://groups.geni.net/geni/raw-attachment/wiki/GEC20Agenda/LabWiki/ModuleA/Execute/LW-executing.png

Now the window lists experiment properties, one or several live graphs (if they have been specified in the OEDL script), and logging information. The latter would be a good starting point for trouble shooting, should your experiment not run as expected.

Depending on the status of your resources and experiments, you will see one of the following statuses at the top of the Execute window:

  • Pending - This is the first state of your experiment where the job scheduler adds it to the run queue. This status would remain for the first few seconds before it changes to Running or Failed
  • Running - This status appears when your experiment starts running. If it fails for one or more reasons, a Failed status will appear instead
  • Aborted - When you click on "Stop Experiment" at the top-left corner of the Execute window, the status changes to aborted
  • Finished - When your experiment is done, you will see this status

Note to the Instructors

  • Students can be asked to implement a particular functionality of the OpenFlow controller. A template should be given to them
  • LabWiki has a new feature that enables the instructor to auto-grade the students' experiments. LabWiki allows people to write user-defined event, which is triggered upon an

experiment-generated measurements reaching a specific value. In the above script, the event will be triggered when Node A is able to ping all the other nodes in the topology. It will trigger a ping event to itself on Node A. In this way, you can say that the experiment is run successfully if the Ping on Node A is seen on the graph

Next: Finish

Design

Attachments (5)

Download all attachments as: .zip