wiki:GENIRacksHome/InstageniRacks/AcceptanceTestStatus/IG-MON-2

Version 5 (modified by chaos@bbn.com, 12 years ago) (diff)

--

Detailed test plan for IG-MON-2: GENI Software Configuration Inspection Test

This page is GPO's working page for performing IG-MON-2. It is public for informational purposes, but it is not an official status report. See GENIRacksHome/InstageniRacks/AcceptanceTestStatus for the current status of InstaGENI acceptance tests.

Last substantive edit of this page: 2012-05-28

Page format

  • The status chart summarizes the state of this test
  • The high-level description from test plan contains text copied exactly from the public test plan and acceptance criteria pages.
  • The steps contain things i will actually do/verify:
    • Steps may be composed of related substeps where i find this useful for clarity
    • Each step is either a preparatory step (identified by "(prep)") or a verification step (the default):
      • Preparatory steps are just things we have to do. They're not tests of the rack, but are prerequisites for subsequent verification steps
      • 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.

Status of test

Step State Date completed Open Tickets Closed Tickets/Comments
1 Color(green,Pass)? 2012-05-17
2 Color(orange,Blocked)? blocked on availability of OpenFlow InstaGENI experiments; blocked on inquiry about state of bound VLAN requests
3 Color(orange,Blocked)? blocked on availability of FOAM
4 Color(orange,Blocked)? blocked on availability of FOAM

High-level description from test plan

This test inspects the state of the GENI AM software in use on the rack.

Procedure

  • 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 InstaGENI resources:
    • How many experimental nodes are available for bare metal use, how many are configured as OpenVZ containers, and how many are configured as PlanetLab containers.
    • What operating system each OpenVZ container makes available for experimental VMs.
    • How many unbound VLANs are in the rack's available pool.
    • Whether the ProtoGENI and FOAM AMs trust the pgeni.gpolab.bbn.com slice authority, which will be used for testing.
  • A site administrator uses available system data sources to determine the configuration of OpenFlow resources according to FOAM, InstaGENI, and FlowVisor.

Criteria to verify as part of this test

  • 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)
  • 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)
  • 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)

Step 1: determine experimental node allocations

Using:

  • On boss and ops, use available system data sources (process listings, monitoring output, system logs, etc) and/or AM administrative interfaces (Emulab UI, testbed database) to determine the experimental state of each node.
  • For each OpenVZ node found, determine what operating system that node makes available to users.

Verify:

  • The site administrator can determine how many nodes are allocated for OpenVZ or PlanetLab use, and how many are available for experimental use, right now.

Results of testing step 1: 2012-05-17

  • As a site admin:
    • Browse to https://boss.utah.geniracks.net/nodecontrol_list.php3?showtype=dl360
    • Login
    • Enter red dot mode
    • The white dots in the "Up?" column and lack of Name/PID/EID info show that pc1, pc2, and pc4 are available for experimenter use, and are not in use right now
    • pc3 and pc5 are in use. Of these:
      • pc5 is in an special experiment, emulab-ops/shared-nodes, and is running the OS FEDORA15-OPENVZ-STD. It's a reasonable guess that this is the OpenVZ shared node, which provides Fedora 15 VMs to experimenters. Browsing to https://boss.utah.geniracks.net/showexp.php3?pid=emulab-ops&eid=shared-nodes#nsfile, corroborate that by finding the setting:
        tb-set-node-sharingmode $vhost1 "shared_local"
        
      • pc3 is not special. It is an experimental node which is in use.
    • Thus, a site admin can learn that the current allocation is 1 OpenVZ node, 0 PlanetLab nodes, and 4 experimental nodes.
  • As an experimenter, run:
    omni -a http://www.utah.geniracks.net/protogeni/xmlrpc/am listresources -o
    
    and view the output. Learn the following things:
    • the node entry for pc3 has a field showing it's unavailable (this is "true" for e.g. pc1):
             <available now="false"/>    
      
    • the node entry for pc5 contains these lines (10034 is the OSID for FEDORA15-OPENVZ-STD, though i don't know how you'd know that as an experimenter. But "pcshared" seems like a clue):
             <emulab:fd name="pcshared" violatable="true" weight="1.0"/>    
             <emulab:fd name="OS-10034" weight="0.5"/>    
      
    • also, the node entry for pc5 contains 49 slots of type "pcvm", whereas the other nodes contain 50. I bet that is a clue to how many VMs pc5 thinks it can run, since i have one VM allocated on there right now (that is, i bet pc5 thinks it can allocate 50 VMs):
            <hardware_type name="pcvm">
                <emulab:node_type type_slots="49"/>
            </hardware_type>
      

Step 2: determine rack VLAN configuration

Using:

  • On boss and ops, use available data sources to determine how many VLANs on the experimental switch are available for experimenters to use
  • For each available experimental VLAN, determine whether it is available for exclusive OpenFlow control
  • Determine what bound VLANs are available for use

Verify:

  • The site administrator can determine how many unbound VLANs are available for use
  • The site administrator can determine which VLANs InstaGENI is able to configure for OpenFlow use
  • The site administrator can determine what bound VLANs are available for use

Results of testing step 2: 2012-05-28

  • On boss, use the database to find out the set of VLANs which can be used for dedicated experiments:
    boss,[~],12:19(0)$ mysql tbdb
    mysql> select stack_id,min_vlan,max_vlan,leader from switch_stack_types;
    +------------+----------+----------+-----------+
    | stack_id   | min_vlan | max_vlan | leader    |
    +------------+----------+----------+-----------+
    | Control    |      128 |      256 | procurve1 | 
    | Experiment |      257 |      999 | procurve2 | 
    +------------+----------+----------+-----------+
    2 rows in set (0.00 sec)
    
  • I am confused by this, because, looking at procurve1:
    ProCurve Switch 2610-24# show vlans 
    ...
      VLAN ID Name                             | Status     Voice Jumbo
      ------- -------------------------------- + ---------- ----- -----
      1       DEFAULT_VLAN                     | Port-based No    No   
      257     _42                              | Port-based No    No   
      260     _44                              | Port-based No    No   
    
    Why are VLANs in the experimental range on the control switch? Incidentally, the mac-address table doesn't show any VLANs in that range, but i am confused by this.
  • I went ahead and created a sliver containing two virtual nodes and a virtual LAN:
    omni -a http://www.utah.geniracks.net/protogeni/xmlrpc/am createsliver ecgtest2 ~/omni/rspecs/request/rack-testing/acceptance-tests/IG-MON-nodes-C.rspec
    
  • That did not generate any additional VLANs on the control switch. I can't experiment with a physical node because there aren't any free right now.

Anyway, i also can't look into OpenFlow options because that's not implemented yet.

I have an open question on the list about bound VLANs, and i'm blocked on that to look into bound VLANs.

Step 3: determine which GENI SAs are trusted by InstaGENI AM

Using:

  • On boss, use available system data sources and/or AM administrative interfaces to determine which GENI slice authorities the InstaGENI AM trusts.
  • On foam, use available system data sources and/or AM administrative interfaces to determine which GENI slice authorities the FOAM AM trusts.
  • Use the GENI AM API to verify that the BBN and Utah InstaGENI AMs trust the pgeni.gpolab.bbn.com SA.
  • Use the GENI AM API to verify that the BBN and Utah FOAM AMs trusts the pgeni.gpolab.bbn.com SA.

Verify:

  • The site administrator can determine the full set of trusted GENI slice authorities on the local rack.
  • An experimenter can verify that the four AMs to be used in the test trust the pgeni.gpolab.bbn.com SA.

Step 4: determine rack OpenFlow state

Using:

  • From a login to the dataplane switch, view the OpenFlow configuration.
  • On flowvisor, use fvctl to view the set of devices reporting to the FlowVisor
  • Use the GENI AM API to view the set of datapaths advertised by FOAM
  • On boss or ops, use available system or AM tools to determine the configuration which the InstaGENI AM will use to install OpenFlow configuration on the switch and share it with FOAM

Verify:

  • All datapaths on the rack switch report either to FlowVisor or directly to experimental controllers
  • All datapaths on the rack switch which are shared with FlowVisor are advertised by FOAM
  • All datapaths reporting to FlowVisor or to FOAM come from the rack switch
  • A site administrator can look at flowvisor's state using fvctl
  • A site administrator can look at FOAM's state using foamctl
  • A site administrator can look at InstaGENI's OpenFlow configuration

Attachments (3)

Download all attachments as: .zip