Changes between Version 4 and Version 5 of GENIRacksProjects/AcceptanceTestsCriteria


Ignore:
Timestamp:
04/11/12 17:24:08 (12 years ago)
Author:
tupty@bbn.com
Comment:

Adding in initial InstaGENI Acceptance Criteria mapping

Legend:

Unmodified
Added
Removed
Modified
  • GENIRacksProjects/AcceptanceTestsCriteria

    v4 v5  
    189189 * II.14. An experimenter can install flows that match only on layer 2 fields, and confirm whether the matching is done in hardware. (C.2.f)
    190190 * II.15. If supported by the rack, an experimenter can install flows that match only on layer 3 fields, and confirm whether the matching is done in hardware. (C.2.f)
     191
     192== InstaGENI Test Case Mapping to Acceptance Criteria Mapping ==
     193
     194Test case mappings to acceptance criteria are specific to the rack project. As more [wiki:GENIRacksProjects#AcceptanceTestPlans Acceptance Test Plans] are added, the acceptance criteria remain common, but the mapping to test cases may differ. InstaGENI specific test case mappings will be captured in this section.
     195
     196=== Administration Acceptance Test Requirements Mapping ===
     197
     198==== IG-ADM-1: Rack Receipt and Inventory Test ====
     199
     200==== IG-ADM-2: Rack Administrator Access Test ====
     201
     202==== IG-ADM-3: Full Rack Reboot Test ====
     203
     204==== IG-ADM-4: Emergency Stop Test ====
     205
     206==== IG-ADM-5: Software Update Test ====
     207
     208==== IG-ADM-6: Control Network Disconnection Test ====
     209
     210==== IG-ADM-7: Documentation Review Test ====
     211
     212=== Monitoring Acceptance Test Requirements Mapping ===
     213
     214==== IG-MON-1: Control Network Software and VLAN Inspection Test ====
     215
     216==== IG-MON-2: GENI Software Configuration Inspection Test ====
     217
     218==== IG-MON-3: GENI Active Experiment Inspection Test ====
     219
     220==== IG-MON-4: Infrastructure Device Performance Test ====
     221
     222==== IG-MON-5: GMOC Data Collection Test ====
     223
     224=== Experimenter Acceptance Test Requirements Mapping ===
     225
     226==== IG-EXP-1: Bare Metal Support Acceptance Test ====
     227 * III.01. A recent Linux OS image for bare-metal nodes is provided by the rack team, and an experimenter can reserve and boot a bare-metal node using this image. (C.1.b)
     228 * III.02. A recent Microsoft OS image for bare-metal nodes is provided by the rack team, and an experimenter can reserve and boot a bare-metal node using this image. (C.1.d)
     229
     230==== IG-EXP-2: InstaGENI Single Site Acceptance Test ====
     231 * I.02. If two experimenters have compute resources on the same rack, they cannot use the control plane to access each other's resources (e.g. via unauthenticated SSH, shared writable filesystem mount) (C.1.a)
     232 * I.03. If two experimenters reserve exclusive VLANs on the same rack, they cannot see or modify each other's dataplane traffic on those exclusive VLANs. (C.1.a)
     233 * I.04. An experimenter can create and access a sliver containing a bare-metal node on the rack. (C.1.b)
     234{{{
     235 * I.21. An experimenter can reserve a VM on the rack, and can run any command with root privileges within the VM OS, including loading a kernel module in any VM OS with a modular kernel. (G.1)
     236 <TU> I am not convinced that this will work, and have said so in my notes.
     237 <TU> We will ask about this in the call.
     238}}}
     239 * I.25. An experimenter can request a publically routable IP address or public TCP/UDP port mapping for the control interface of any compute resource in their sliver (subject to availability of IPs at the site), and can access their resource at that IP address and/or port from the commodity internet, and send traffic outbound from their resource to the internet. (F.1)
     240{{{
     241 * III.04. An experimenter can view a list of OS images which can be loaded on VMs by requesting an advertisement RSpec from the compute aggregate. (C.1.e)
     242 <TU> I am not sure what we expect to happen here... which base OSes can be loaded on a shared node?  Is that what is listed?
     243 <TU> We think that an experimenter may be able to choose different userspace types (like Ubuntu userspace, etc), and we will ask about this on the call.
     244}}}
     245 * III.05. An experimenter can view a list of OS images which can be loaded on bare-metal nodes by requesting an advertisement RSpec from the compute aggregate. (C.1.e)
     246{{{
     247 * III.06. The procedure for an experimenter to have new VM images added to the rack has been documented, including any restrictions on what OS images can be run on VMs. (C.1.e)
     248 <TU> Again, not sure what we expect here
     249 <TU> Maybe we need to ask about adding new userspace types on shared nodes.
     250}}}
     251 * III.07. The procedure for an experimenter to have new bare-metal images added to the rack has been documented, including any restrictions on what OS images can be run on bare-metal nodes. (C.1.e)
     252
     253==== IG-EXP-3: InstaGENI Single Site Limits Test ====
     254 * I.01. 100 experimental VMs can run on the rack simultaneously (C.1.a) 
     255 * I.18. If multiple VMs use the same physical interface to carry dataplane traffic, each VM has a distinct MAC address for that interface. (C.2.d, G.4)
     256{{{
     257 * III.03. A recent Linux OS image for VMs is provided by the rack team, and an experimenter can reserve and boot a VM using this image. (C.1.e)
     258 <TU> If they provide an image that runs OpenVZ, then that is good enough, right?
     259 <TU> This would by default provide at least some userspace type.
     260}}}
     261
     262==== IG-EXP-4: InstaGENI Multi-site Acceptance Test ====
     263 * I.05. An experimenter can create and access a sliver containing both a VM and a bare-metal node. (C.1.c)
     264 * I.06. An experimenter can create and access a sliver containing a VM and a bare-metal node, each with a dataplane interface on the same VLAN. (C.1.c)
     265 * I.07. If an experimenter creates a sliver containing a VM and a bare-metal node, each with a dataplane interface on the same VLAN, the nodes can communicate on that VLAN. (C.1.c) 
     266 * I.19. An experimenter can request an unbound exclusive VLAN from a local aggregate manager in the rack, and dataplane traffic can be sent on that VLAN and seen on the campus's primary dataplane switch. (C.2.e)
     267 * I.20. An experimenter can allocate and run a slice in which a compute resource in the rack sends traffic via an unbound exclusive rack VLAN, traversing a dynamically-created topology in a core L2 network, to another rack's dataplane. (C.2.e)
     268 * I.22. An experimenter can create and access an experiment which configures a bare-metal compute resource to have at least two logical dataplane interfaces with distinct MAC addresses. (G.2)
     269 * I.23. An experimenter can create and access an experiment which configures a VM compute resource to have at least two logical dataplane interfaces with distinct MAC addresses. (G.2)   
     270 * I.24. An experimenter can create and access an experiment containing a compute resource with a dataplane interface, and can construct and send a non-IP ethernet packet over the dataplane interface. (G.3)
     271
     272==== IG-EXP-5: InstaGENI OpenFlow Network Resources Acceptance Test ====
     273 * II.04. An experimenter can create a sliver including a subset of the traffic of a bound shared VLAN, define that subset using flowspace rules, and have that subset controlled by a controller that they run. (C.2.f)
     274 * II.08. If an experimenter creates an OpenFlow sliver on a shared VLAN, the experimenter's controller receives OpenFlow control requests only for traffic assigned to their sliver, and can successfully insert flowmods or send packet-outs only for traffic assigned to their sliver. (C.2.f)
     275
     276==== IG-EXP-6: InstaGENI and Meso-scale Multi-site !OpenFlow Acceptance Test ====
     277 * I.10. An experimenter can create and access a sliver containing a compute resource in the rack with a dataplane interface connected to a bound VLAN. (C.2.b, C.2.e)
     278 * I.11. An experimenter can create and access a sliver containing a compute resource in the rack with a dataplane interface connected to a shared VLAN, and can specify what IP address should be assigned to the dataplane interface connected to that shared VLAN. (C.2.b)
     279
     280 * I.12. Two experimenters can create and access slivers containing a compute resource in the rack with a dataplane interface connected to the same bound shared VLAN. (C.2.b, C.2.e)
     281 * I.15. An experimenter can create and access a sliver containing multiple compute resources in the rack with a dataplane interface on each connected to the same bound VLAN. (C.2.b)
     282 * I.17. An experimenter can create and access a sliver containing at least one bare-metal node and at least two VMs in the rack, and each compute resource must be allowed to have a dataplane interface on a single bound VLAN. (C.2.c)
     283 * II.01. If multiple VMs use the same physical interface to carry dataplane traffic, traffic between the VM dataplane interfaces can be OpenFlow-controlled. (C.2.d) (G.4)
     284 * II.05. An experimenter can run a controller (for any type of OpenFlow sliver) on an arbitrary system, accessible via the public Internet or via a private network which the rack FlowVisor can access, by specifying the DNS hostname (or IP address) and TCP port, as part of their sliver request. (C.2.f)
     285 * II.07. If an experimenter creates a sliver containing a compute resource with a dataplane interface on a shared VLAN, only the subset of traffic on the VLAN which has been assigned to their sliver is visible to the dataplane interface of their compute resource. (C.2.f)
     286 * II.09. Traffic only flows on the network resources assigned to experimenters' slivers as specified by the experimenters' controllers. No default controller, switch fail-open behavior, or other resource other than experimenters' controllers, can control how traffic flows on network resources assigned to experimenters' slivers. (C.2.f)
     287 * II.10. An experimenter can set the hard and soft timeout of flowtable entries that their controller adds to the switch. (C.2.f)
     288 * II.11. An experimenter's controller can get switch statistics and flowtable entries for their sliver from the switch. (C.2.f)
     289 * II.12. An experimenter's controller can get layer 2 topology information about their sliver, and about other slivers in their slice. (C.2.f)
     290 * II.13. An experimenter can access documentation about which OpenFlow actions can be performed in hardware. (C.2.f)
     291 * II.14. An experimenter can install flows that match only on layer 2 fields, and confirm whether the matching is done in hardware. (C.2.f)
     292 * II.15. If supported by the rack, an experimenter can install flows that match only on layer 3 fields, and confirm whether the matching is done in hardware. (C.2.f)
     293
     294==== IG-EXP-7: Click Router Experiment Acceptance Test ====
    191295
    192296