Versions Compared

Old Version 2

changes.mady.by.user Former user

Saved on

compared with

New Version 3

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

By design, Floodlight is meant to be an open source controller for OpenFlow applications and/or controller features to be built on. Over time, Floodlight will grow with the open source community's contribution into a sound and stable controller platform. OpenBench will provide the test tools and process to assure the sound growth of floodlight.

System requirements

  1. VirtualBox v4.1.14 or later (earlier versions may work but have not been tested)
  2. Internet connectivity for initial installation
  3. Floodlight vmdk

Installation procedure

1. On host, obtain floodlight-vm.zip from

...

http://floodlight.openflowhub.org/download/

...

; unzip it in your favorite working directory, say ~/work

2. On host, obtain VM create/setup scripts

...

by:

    • git clone git@github.com:kwanggithub/floodlighttest

...

    • scripts are under floodlighttest/scripts

...

3. Either a) rename unzipped VM folder name to default name given in onetime-create-vm.sh (i.e., floodlightcontroller-test), or

...

b)

...

edit the folder name in onetime-create-vm.sh to match the VM folder (i.e., floodlightcontroller-release date). 

4. On host, run onetime-create-vm.sh; in VirtualBox GUI, click "Network" tab and "OK" for all VMs (default three)

...

, then click to start them, log in each (username: floodlight, no password), run 'ifconfig' to confirm and note down eth0 IP address

5. On host, edit onetime-setup-vm.sh and setup-bench.sh with the found VM IP addresses; run onetime-setup-vm.sh

...

which will log into one VM (consolve-vm) and install FloodlightTest from github.

Running tests

Each time you want to start running tests, you will click start all VM(s) from VirtualBox GUI and do the following:

1. Update floodlight.jar (and floodlight.properties) if needed:

    • If you have not changed your floodlight code (i.e., floodlight.jar is up-to-date on your test VMs), you can simply start the three VMs (one console, two testers)
    • If you do need to update your floodlight.jar, a convenience script is provided. On host, confirm/update path to your floodlight source root directory in update-floodlight.sh; confirm/update VM IP addresses in update-floodlight.sh. Run update-floodlight.sh which builds (with ant), uploads, and runs latest floodlight.jar on VM(s)

2. On "console" VM, 'cd floodlighttest' and then 'source setup-python-env.sh'

3. On "console" VM, 'bm clean' which cleans up any old VM states from previous runs.

4.

...

Edit build/Makefile.workspace to confirm/edit VM IP addresses under make target 'register-vms-floodlight'

5. On "console" VM, 'bm register-vms-floodlight'

6. On "console" VM, 'bm check-vms-floodlight'; see failed-check-vms-floodlight file for failed tests, if any

7. On "console" VM, 'bm check-tests-floodlight'; see failed-check-tests file for failed tests, if any

8. On "console" VM, 'bigtest/test-dir/test.py' to run individual failed tests directly to diagnose cause of failure

...

Useful tips:

1. Create a snapshot for the two "tester VMs" in VirtualBox immediately after initial install.  Click a VM, click Snapshots tab on the upper right, and click the plus tab to create a snapshot. It is a recommended practice to check the "Restore current snapshot" check box and power off from time to time to restore initial clean image and avoid false alarms created due to stale image state.  For example, you would certainly want to revert the image after running check-tests-floodlight (or, manually do 'rm /opt/floodlight/floodlight/feature/quantum', then 'sudo service floodlight stop', then sudo service floodlight start') to return floodlight to default mode.  

2. Use terminals to ssh into VMs for to be able to see longer scroll history

23. Most failures of setup or test scripts were due to incorrect/incomplete network setup. Check the following for typical network problems:

  • If your VMs are in the bridged mode as the startup scripts configured: ifconfig on each VM to assure they have received a valid address. If not, confirm whether you are on a network with a DHCP server; whether you have followed instructions above to "click" your VirtualBox VM's GUI Network tab,; others.  If all do not work, you can still assign a static address for each VM with, e.g., 'ifconfig eth0 xx.xx.xx.xx 255.255.255.0'
  • At any time after your initial setup, you are free to change your VirtualBox VMs to use host-only network. If you have not done this before, go to VirtualBox menu bar > VirtualBox > Preferences > Network > Add a host-only Network if you do not already have one (vboxnet0). Then, click each VM's Network tab to switch to host-only Adapter/vboxnet0.  The host only network automatically runs a DHCP server, such that your host is. e.g., 192.168.56.1, and your VMs will have 192.168.56.[101, 102, 103]. 

Base test suite

Each test suite is simply a batch file with a number of lists.  You can open each one to see what tests are being run.  Each suite at the end produces a failed_(suite name) file showing any individual tests that failed. All tests are based on mininet.  A test can have either one or two floodlight controller running.

1. check-vms-floodlight

...

: Currently consisting only one test called SmokeTest1, essentially a simple stress test for floodlight.
2. check-tests-floodlight

...

: Currently containing ten tests grouped into five categories:

  • floodlight: testing switch-controller connection under switch restart and handling of switches with same (conflict) DPID (keeping the last connection).
  • forwarding: testing forwarding among OF and non-OF islands, moving hosts, and no path scenarios
  • rest: Floodlight rest API test
  • staticflowpusher: Static Flow Entry Pusher test
  • openstack: quantum plugin + virtual network filter test.  This test restarts floodlight with a different configuration property file (quantum.properties).  After running this test, make sure you either revert the VM to initial snapshot, or manually do 'rm /opt/floodlight/floodlight/feature/quantum', then 'sudo service floodlight stop', then sudo service floodlight start' to return floodlight to default mode.

Requirements for merging floodlight extensions

Floodlight enforces strict software engineering practice for quality assurance. All modules within floodlight must be accompanied with unit tests and integration tests provided by the developer(s).

1. JUnit unit tests. Code coverage threshold, eclipse, bm check
2. OpenBench integration tests
3. Floodlight committer tests and code review

Adding new integration tests

...
Example
...

Adding new unit tests

...
Example
...