Changes between Initial Version and Version 1 of GENIRacksHome/InstageniRacks/AcceptanceTestStatus/IG-MON-3


Ignore:
Timestamp:
05/12/12 17:22:48 (12 years ago)
Author:
chaos@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIRacksHome/InstageniRacks/AcceptanceTestStatus/IG-MON-3

    v1 v1  
     1[[PageOutline]]
     2
     3= Detailed test plan for IG-MON-3: GENI Active Experiment Inspection Test =
     4
     5''This page is GPO's working page for performing IG-MON-3.  It is public for informational purposes, but it is not an official status report.  See [wiki:GENIRacksHome/InstageniRacks/AcceptanceTestStatus] for the current status of InstaGENI acceptance tests.''
     6
     7''Last substantive edit of this page: 2012-05-08''
     8
     9== Page format ==
     10
     11 * The status chart summarizes the state of this test
     12 * The high-level description from test plan contains text copied exactly from the public test plan and acceptance criteria pages.
     13 * The steps contain things i will actually do/verify:
     14   * Steps may be composed of related substeps where i find this useful for clarity
     15   * Each step is either a preparatory step (identified by "(prep)") or a verification step (the default):
     16     * Preparatory steps are just things we have to do.  They're not tests of the rack, but are prerequisites for subsequent verification steps
     17     * Verification steps are steps in which we will actually look at rack output and make sure it is as expected.  They contain a '''Using:''' block, which lists the steps to run the verification, and an '''Expect:''' block which lists what outcome is expected for the test to pass.
     18
     19== Status of test ==
     20
     21|| '''Step''' || '''State'''               || '''Date completed''' || '''Tickets''' || '''Comments'''                                                                                      ||
     22|| 1          || [[Color(orange,Blocked)]] ||                      ||               || blocked on availability of local SM                                                                 ||
     23|| 2          ||                           ||                      ||               || ready to test                                                                                       ||
     24|| 3          || [[Color(orange,Blocked)]] ||                      ||               || blocked on availability of local SM, blocked on ability to request OpenFlow resources from local SM ||
     25|| 4          || [[Color(orange,Blocked)]] ||                      ||               || blocked on 1 and 3                                                                                  ||
     26|| 5          || [[Color(orange,Blocked)]] ||                      ||               || blocked on 1 and 3                                                                                  ||
     27|| 6          || [[Color(orange,Blocked)]] ||                      || exoticket:10  || blocked on 1, 3, availability of FOAM                                                               ||
     28|| 7          || [[Color(orange,Blocked)]] ||                      || exoticket:10  || blocked on 1, 3                                                                                     ||
     29|| 8          || [[Color(orange,Blocked)]] ||                      || exoticket:10  || blocked on 1, 3                                                                                     ||
     30== High-level description from test plan ==
     31
     32This test inspects the state of the rack data plane and control networks when experiments are running, and verifies that a site administrator can find information about running experiments.
     33
     34=== Procedure ===
     35
     36 * An experimenter from the GPO starts up experiments to ensure there is data to look at:
     37   * An experimenter runs an experiment containing at least one rack OpenVZ VM, and terminates it.
     38   * An experimenter runs an experiment containing at least one rack OpenVZ VM, and leaves it running.
     39 * A site administrator uses available system and experiment data sources to determine current experimental state, including:
     40   * How many VMs are running and which experimenters own them
     41   * How many physical hosts are in use by experiments, and which experimenters own them
     42   * How many VMs were terminated within the past day, and which experimenters owned them
     43   * What !OpenFlow controllers the data plane switch, the rack !FlowVisor, and the rack FOAM are communicating with
     44 * A site administrator examines the switches and other rack data sources, and determines:
     45   * What MAC addresses are currently visible on the data plane switch and what experiments do they belong to?
     46   * For some experiment which was terminated within the past day, what data plane and control MAC and IP addresses did the experiment use?
     47   * For some experimental data path which is actively sending traffic on the data plane switch, do changes in interface counters show approximately the expected amount of traffic into and out of the switch?
     48
     49=== Criteria to verify as part of this test ===
     50
     51 * VII.09. A site administrator can determine the MAC addresses of all physical host interfaces, all network device interfaces, all active experimental VMs, and all recently-terminated experimental VMs. (C.3.f)
     52 * VII.11. A site administrator can locate current configuration of flowvisor, FOAM, and any other OpenFlow services, and find logs of recent activity and changes. (D.6.a)
     53 * VII.18. Given a public IP address and port, an exclusive VLAN, a sliver name, or a piece of user-identifying information such as e-mail address or username, a site administrator or GMOC operator can identify the email address, username, and affiliation of the experimenter who controlled that resource at a particular time. (D.7)
     54
     55== Step 1 (prep): start a VM experiment and terminate it ==
     56
     57 * An experimenter requests an experiment from the InstaGENI AM containing two rack VMs and a dataplane VLAN
     58 * The experimenter logs into a VM, and sends dataplane traffic
     59 * The experimenter terminates the experiment
     60
     61== Step 2 (prep): start a bare metal node experiment and terminate it ==
     62
     63 * An experimenter requests an experiment from the InstaGENI AM containing two rack hosts and a dataplane VLAN
     64 * The experimenter logs into a host, and sends dataplane traffic
     65 * The experimenter terminates the experiment
     66
     67== Step 3 (prep): start an experiment and leave it running ==
     68
     69 * An experimenter requests an experiment from the InstaGENI AM containing two rack VMs connected by an OpenFlow-controlled dataplane VLAN
     70 * The experimenter configures a simple OpenFlow controller to pass dataplane traffic between the VMs
     71 * The experimenter logs into one VM, and begins sending a continuous stream of dataplane traffic
     72
     73== Step 4: view running VMs ==
     74
     75'''Using:'''
     76 * On boss, use AM state, logs, or administrator interfaces to determine:
     77   * What experiments are running right now
     78   * How many VMs are allocated for those experiments
     79   * Which OpenVZ node is each VM running on
     80 * On OpenVZ nodes, use system state, logs, or administrative interfaces to determine what VMs are running right now, and look at any available configuration or logs of each.
     81
     82'''Verify:'''
     83 * A site administrator can determine what experiments are running on the InstaGENI AM
     84 * A site administrator can determine the mapping of VMs to active experiments
     85 * A site administrator can view some state of running VMs on the VM server
     86
     87== Step 5: get information about terminated experiments ==
     88
     89'''Using:'''
     90 * On boss, use AM state, logs, or administrator interfaces to find evidence of the two terminated experiments.
     91 * Determine how many other experiments were run in the past day.
     92 * Determine which GENI user created each of the terminated experiments.
     93 * Determine the mapping of experiments to OpenVZ or exclusive hosts for each of the terminated experiments.
     94 * Determine the control and dataplane MAC addresses assigned to each VM in each terminated experiment.
     95 * Determine any IP addresses assigned by InstaGENI to each VM in each terminated experiment.
     96
     97'''Verify:'''
     98 * A site administrator can get ownership and resource allocation information for recently-terminated experiments which used OpenVZ VMs.
     99 * A site administrator can get ownership and resource allocation information for recently-terminated experiments which used physical hosts.
     100 * A site administrator can get information about MAC addresses and IP addresses used by recently-terminated experiments.
     101
     102== Step 6: get !OpenFlow state information ==
     103
     104'''Using:'''
     105 * On the dataplane switch, get a list of controllers, and see if any additional controllers are serving experiments.
     106 * On the flowvisor VM, get a list of active FV slices from the !FlowVisor
     107 * On the FOAM VM, get a list of active slivers from FOAM
     108 * Use FV, FOAM, or the switch to list the flowspace of a running !OpenFlow experiment.
     109
     110'''Verify:'''
     111 * A site administrator can get information about the !OpenFlow resources used by running experiments.
     112 * When an !OpenFlow experiment is started by InstaGENI, a new controller is added directly to the switch.
     113 * No new !FlowVisor slices are added for new !OpenFlow experiments started by InstaGENI.
     114 * No new FOAM slivers are added for new !OpenFlow experiments started by InstaGENI.
     115
     116== Step 7: verify MAC addresses on the rack dataplane switch ==
     117
     118'''Using:'''
     119 * Establish a privileged login to the dataplane switch
     120 * Obtain a list of the full MAC address table of the switch
     121 * On boss and the experimental hosts, use available data sources to determine which host or VM owns each MAC address.
     122
     123'''Verify:'''
     124 * It is possible to identify and classify every MAC address visible on the switch
     125
     126== Step 8: verify active dataplane traffic ==
     127
     128'''Using:'''
     129 * Establish a privileged login to the dataplane switch
     130 * Based on the information from Step 7, determine which interfaces are carrying traffic between the experimental VMs
     131 * Collect interface counters for those interfaces over a period of 10 minutes
     132 * Estimate the rate at which the experiment is sending traffic
     133
     134'''Verify:'''
     135 * The switch reports interface counters, and an administrator can obtain plausible estimates of dataplane traffic quantities by looking at them.
     136