| | 1 | [[PageOutline]] |
| | 2 | |
| | 3 | = Detailed test plan for EG-MON-2: GENI Software Configuration Inspection Test = |
| | 4 | |
| | 5 | ''This page is GPO's working page for performing EG-MON-2. It is public for informational purposes, but it is not an official status report. See [wiki:GENIRacksHome/ExogeniRacks/AcceptanceTestStatus] for the current status of ExoGENI acceptance tests.'' |
| | 6 | |
| | 7 | ''Last substantive edit of this page: 2012-05-03'' |
| | 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 | Meaning of states: |
| | 22 | * [[Color(green,okay)]]: Step is completed and passed (for a verification step), or is completed (for a prep step) |
| | 23 | * [[Color(red,failed)]]: 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,waiting)]]: Step is blocked by some other step or activity |
| | 26 | |
| | 27 | || '''Step''' || '''State''' || '''Date completed''' || '''Comments''' || |
| | 28 | || 1 || || || || |
| | 29 | || 2 || || || || |
| | 30 | || 3 || || || || |
| | 31 | || 4 || || || || |
| | 32 | |
| | 33 | == High-level description from test plan == |
| | 34 | |
| | 35 | This test inspects the state of the GENI AM software in use on the rack. |
| | 36 | |
| | 37 | === Procedure === |
| | 38 | |
| | 39 | * A site administrator uses available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces to determine the configuration of ExoGENI resources: |
| | 40 | * How many VMs are assigned to each of the BBN rack SM and the global ExoSM |
| | 41 | * How many bare metal nodes are configured on the rack and whether they are controlled by the BBN rack SM or by ExoSM. |
| | 42 | * How many unbound VLANs are in the rack's available pool and whether they are controlled by the BBN rack SM or by ExoSM. |
| | 43 | * Whether the BBN ExoGENI AM, the RENCI ExoGENI AM, and ExoSM trust the pgeni.gpolab.bbn.com slice authority, which will be used for testing. |
| | 44 | * A site administrator uses available system data sources to determine the configuration of !OpenFlow resources according to FOAM, ExoGENI, and !FlowVisor. |
| | 45 | |
| | 46 | === Criteria to verify as part of this test === |
| | 47 | |
| | 48 | * VI.12. A public document describes all the GENI experimental resources within the rack, and explains what policy options exist for each, including: how to configure rack nodes as bare metal vs. VM server, what options exist for configuring automated approval of compute and network resource requests and how to set them, how to configure rack aggregates to trust additional GENI slice authorities, whether it is possible to trust local users within the rack. (F.7) |
| | 49 | * VI.13. A public document describes the expected state of all the GENI experimental resources in the rack, including how to determine the state of an experimental resource and what state is expected for an unallocated bare metal node. (F.5) |
| | 50 | * 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) |
| | 51 | |
| | 52 | == Step 1: determine VM resource allocations == |
| | 53 | |
| | 54 | '''Using:''' |
| | 55 | * On bbn-hn, use available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces to determine how many VMs are assigned to each of the BBN rack SM and to the global ExoSM. |
| | 56 | |
| | 57 | '''Verify:''' |
| | 58 | * The site administrator can determine how many VMs are allocated to each SM |
| | 59 | |
| | 60 | == Step 2: determine bare metal node configurations == |
| | 61 | |
| | 62 | '''Using:''' |
| | 63 | * On bbn-hn, use available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces to determine how many nodes in the rack are configured as bare metal nodes, and whether they are controlled by the BBN rack SM or by ExoSM. |
| | 64 | |
| | 65 | '''Verify:''' |
| | 66 | * The site administrator can determine how many bare metal nodes are controlled by the local SM |
| | 67 | * The site administrator can determine where each rack bare metal node's controller is if the controller is not the local SM |
| | 68 | |
| | 69 | == Step 2: determine available VLAN pool == |
| | 70 | |
| | 71 | '''Using:''' |
| | 72 | * On bbn-hn, use available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces to determine how many unbound VLANs are available for rack use, and whether they are allocated by the local rack SM or by ExoSM. |
| | 73 | * On bbn-hn, use available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces to determine whether any bound VLANs are available for rack use, and whether they are allocated by the local rack SM or by ExoSM. |
| | 74 | |
| | 75 | '''Verify:''' |
| | 76 | * The site administrator can determine how many unbound VLANs are available for use and where they are allocated. |
| | 77 | * The site administrator can determine what bound VLANs are available for use and where they are allocated. |
| | 78 | |
| | 79 | == Step 3: determine which GENI SAs are trusted == |
| | 80 | |
| | 81 | '''Using:''' |
| | 82 | * On bbn-hn, use available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces to determine which GENI slice authorities the local rack SM trusts. |
| | 83 | * Use the GENI AM API to verify that the BBN ExoGENI AM, the RENCI ExoGENI AM and the ExoSM trust the pgeni.gpolab.bbn.com SA. |
| | 84 | * Use the GENI AM API to verify that the rack FOAM instance trusts the pgeni.gpolab.bbn.com SA. |
| | 85 | |
| | 86 | '''Verify:''' |
| | 87 | * The site administrator can determine the full set of trusted GENI slice authorities on the local rack. |
| | 88 | * An experimenter can verify that the four AMs to be used in the test trust the pgeni.gpolab.bbn.com SA. |
| | 89 | |
| | 90 | == Step 4: determine rack !OpenFlow state == |
| | 91 | |
| | 92 | '''Using:''' |
| | 93 | * From a login to the 8264 (dataplane) switch, view the !OpenFlow configuration. |
| | 94 | * On bbn-hn, use fvctl to view the set of devices reporting to the !FlowVisor |
| | 95 | * Use the GENI AM API to view the set of datapaths advertised by FOAM |
| | 96 | |
| | 97 | '''Verify:''' |
| | 98 | * All datapaths on the rack switch report either to !FlowVisor or to FOAM |
| | 99 | * All datapaths reporting to !FlowVisor or to FOAM come from the rack switch |
| | 100 | * A site administrator can look at flowvisor's state using fvctl |
| | 101 | * A site administrator can look at FOAM's state using foamctl |
| | 102 | |
