| 191 | |
| 192 | == InstaGENI Test Case Mapping to Acceptance Criteria Mapping == |
| 193 | |
| 194 | Test 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 ==== |