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


Ignore:
Timestamp:
05/08/12 18:46:48 (9 years ago)
Author:
chaos@bbn.com
Comment:

--

Legend:

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

    v1 v1  
     1[[PageOutline]]
     2
     3= Detailed test plan for IG-MON-1: Control Network Software and VLAN Inspection Test =
     4
     5''This page is GPO's working page for performing IG-MON-1.  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
     21Meaning of states:
     22 * [[Color(green,Pass)]]: Step is completed and passed (for a verification step), or is completed (for a prep step)
     23 * [[Color(red,Fail)]]: Step is completed and failed, and is not being revisited
     24 * in progress: We are currently testing or iterating on this step
     25 * [[Color(orange,Blocked)]]: Step is blocked by some other step or activity
     26
     27|| '''Step''' || '''State''' || '''Date completed''' || '''Tickets''' || '''Comments''' ||
     28|| 1          || [[Color(orange,Blocked)]] ||                      ||               || blocked on sudo access to boss ||
     29|| 2          || [[Color(orange,Blocked)]] ||                      ||               || blocked on sudo access to ops ||
     30|| 3          || [[Color(orange,Blocked)]] ||                      ||               || blocked on sudo access to foam VM ||
     31|| 4          || [[Color(orange,Blocked)]] ||                      ||               || blocked on sudo access to the control host ||
     32|| 5          || [[Color(orange,Blocked)]] ||                      ||               || blocked on access to an allocated OpenVZ host (e.g. via boss) ||
     33|| 6          || [[Color(orange,Blocked)]] ||                      ||               || blocked on access to the control switch ||
     34
     35== High-level description from test plan ==
     36
     37This test inspects the state of the rack control network, infrastructure nodes, and system software.
     38
     39==== Procedure ====
     40
     41 * A site administrator enumerates processes on each of the server host, the boss VM, the ops VM, the FOAM VM, and an experimental node configured for OpenVZ, which listen for network connections from other nodes, identifies what version of what software package is in use for each, and verifies that we know the source of each piece of software and could get access to its source code.
     42 * A site administrator reviews the configuration of the rack control plane switch and verifies that each experimental node's control and iLO interfaces are on the expected VLANs.
     43 * A site administrator reviews the MAC address table on the control plane switch, and verifies that all entries are identifiable and expected.
     44
     45=== Criteria to verify as part of this test ===
     46
     47 * VI.09. A public document explains how to identify the software versions and system file configurations running on the rack, and how to get information about recent changes to the rack software and configuration. (F.5)
     48 * VI.11. A public document describes the GENI software running on the rack, and explains how to get access to the source code of each piece of GENI software. (F.6)
     49 * VII.03. Site administrators can understand the expected control and dataplane network behavior of their rack. (F.2)
     50 * VII.04. Site administrators can view and investigate current system and network activity on their rack. (F.2)
     51 * VII.06. A site administrator can verify the control software and configurations on the rack at some point in time. (F.5)
     52 * VII.08. A site administrator can get access to source code for the version of each piece of GENI code installed on their site rack at some point in time. (F.6)
     53 * 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)
     54 * VII.10. A site administrator can locate current and recent CPU and memory utilization for each rack network device, and can find recent changes or errors in a log. (D.6.a)
     55 * VII.12. For each infrastructure and experimental host, a site administrator can locate current and recent uptime, CPU, disk, and memory utilization, interface traffic counters, process counts, and active user counts. (D.6.b)
     56 * VII.13. A site administrator can locate recent syslogs for all infrastructure and experimental hosts. (D.6.b)
     57
     58== Step 1: identify network-listening software on the boss node ==
     59
     60'''Using:'''
     61 * Using netstat, enumerate processes on boss which listen for network connections from outside the node
     62 * For each process found:
     63   * Use the command-line to determine what executable file is running
     64   * Use pkg_info to determine whether the executable file is part of a FreeBSD package/port
     65   * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software
     66 * For each FreeBSD package found, identify a location from which the port source can be obtained
     67 * For each non-FreeBSD software source found, identify a location from which the source code for that version can be obtained.
     68
     69'''Verify:'''
     70 * The source of each network-listening file can be identified
     71 * FreeBSD ports can be identified for each FreeBSD-sourced package
     72 * The source code and identifiable version (e.g. a git tag) can be found for each non-FreeBSD software source
     73
     74== Step 2: identify network-listening software on the ops node ==
     75
     76'''Using:'''
     77 * Using netstat, enumerate processes on ops which listen for network connections from outside the node
     78 * For each process found:
     79   * Use the command-line to determine what executable file is running
     80   * Use pkg_info to determine whether the executable file is part of a FreeBSD package/port
     81   * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software
     82 * For each FreeBSD package found, identify a location from which the port source can be obtained
     83 * For each non-FreeBSD software source found, identify a location from which the source code for that version can be obtained.
     84
     85'''Verify:'''
     86 * The source of each network-listening file can be identified
     87 * FreeBSD ports can be identified for each FreeBSD-sourced package
     88 * The source code and identifiable version (e.g. a git tag) can be found for each non-FreeBSD software source
     89
     90== Step 3: identify network-listening software on the foam node ==
     91
     92'''Using:'''
     93 * Using netstat, enumerate processes on foam which listen for network connections from outside the node
     94 * For each process found:
     95   * Use the command-line to determine what executable file is running
     96   * Use dpkg commands to determine whether the executable file is part of a Debian package
     97   * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software
     98 * For each Debian package found, identify a location from which the source package can be obtained
     99 * For each non-Debian package found, identify a location from which the source code for that version can be obtained.
     100
     101'''Verify:'''
     102 * The source of each network-listening file can be identified
     103 * Source code or a source package can be identified for each Debian-sourced package
     104 * The source code and identifiable version (e.g. a git tag) can be found for each non-Debian software source
     105
     106== Step 4: identify network-listening software on the control host ==
     107
     108'''Using:'''
     109 * Using netstat, enumerate processes on the control host which listen for network connections from outside the node
     110 * For each process found:
     111   * Use the command-line to determine what executable file is running
     112   * Use dpkg commands to determine whether the executable file is part of a Debian package
     113   * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software
     114 * For each Debian package found, identify a location from which the source package can be obtained
     115 * For each non-Debian package found, identify a location from which the source code for that version can be obtained.
     116
     117'''Verify:'''
     118 * The source of each network-listening file can be identified
     119 * Source code or a source package can be identified for each Debian-sourced package
     120 * The source code and identifiable version (e.g. a git tag) can be found for each non-Debian software source
     121
     122== Step 5: identify network-listening software on an OpenVZ experimental node ==
     123
     124'''Using:'''
     125 * Using netstat, enumerate processes on an allocated node running the OpenVZ image which listen for network connections from outside the node
     126 * For each process found:
     127   * Use the command-line or `/proc` to determine what executable file is running
     128   * Use RPM tools to determine whether the executable file is part of an RPM
     129   * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software
     130 * For each RPM found, identify a location from which a source RPM for that package can be obtained
     131 * For each non-RPM software source found, identify a location from which the source code for that version can be obtained.
     132
     133'''Verify:'''
     134 * The source of each network-listening file can be identified
     135 * RPM source packages can be found for each RPM-sourced package
     136 * The source code and identifiable version (e.g. a git tag) can be found for each non-RPM software source
     137
     138== Step 6: verify VLANs on the rack management switch ==
     139
     140'''Using:'''
     141 * Establish a privileged login to the control plane switch
     142 * Obtain the list of all VLAN mappings for all interfaces
     143 * Determine which interfaces connect to experimental nodes
     144 * Obtain a list of the full MAC address table of the switch
     145 * Use interface listings on hosts and devices to determine the identities of all MAC addresses
     146
     147'''Verify:'''
     148 * All experimental node control interfaces are on an expected VLAN
     149 * It is possible to identify and classify every MAC address visible on the control switch
     150