|
Requirements CS Management server CP 3.0.6 ACS 4.1 CS Baremetal hosts have IPMI over LAN enabled CS baremetal agent providing external DHCP, PXE server NFS server contains linux-based boot image CIFS/Samba server contains windows-based boot image |
|
|
|
|
|
||
|
Kickstart Supported Guest OS CentOS 6.2 CentOS 6.3 Fedora 17 Ubuntu 12.04 PING style Windows |
|
|
|
|
|
||
|
|
|
|
|
|
|
||
Testcase ID |
Test Description |
Steps |
Expected Results |
Priority |
Type |
Automatable |
||
|
Kickstart Supported Guest OS |
|
|
|
|
|
||
|
CentOS 6.2 |
|
|
P1 |
functional |
|
||
|
CentOS 6.3 |
|
|
P1 |
functional |
|
||
|
Fedora 17 |
|
|
P1 |
functional |
|
||
|
Ubuntu 12.04 |
|
|
P1 |
functional |
|
||
|
PING style Windows |
|
|
P1 |
functional |
|
||
|
|
|
|
|
|
|
||
|
Zone Configuration |
|
|
|
|
|
||
1 |
baremetal network offering |
Create network offering shared, no vlan specify, dhcp, userdata, security group, baremetalPxeService |
|
P1 |
functional |
|
||
2 |
Basic Zone with BareMetal Hypervisor |
Basic Zone with BareMetal Hypervisor |
No SSVM ,CPVM will be launched. There should be no need for configuring Primary/Secondary storage. There should be no need for configuring Pod System ip range. |
P1 |
functional |
|
||
|
Adding Baremetal Host |
|
|
|
|
|
||
3 |
Add Baremetal Host providing valid values for the following: 1.IPMI Ipaddress 2.IPMI account 3.IPMI password 4.Host IP Address - optional 5.Host Mac Address 6.Host tag |
Add Baremetal Host via API addBaremetalHost providing valid values for following: 1.IPMI Ipaddress 2.IPMI account 3.IPMI password 4.Host IP Address - optional 5.Host Mac Address 6.Host tag |
Host addition should succeed. |
P1 |
functional |
|
||
4 |
Add Baremetal Host without Host tags |
Add Baremetal Host without Host tags |
Host addition should fail |
P2 |
negative |
|
||
6 |
Add Baremetal Host without providing a Mac Address |
Add Baremetal Host without providing a Mac Address |
Host addition should fail |
P2 |
negative |
|
||
7 |
Add Baremetal Host without providing IPMI Ipaddress, account and password. |
Add Baremetal Host without providing IPMI Ipaddress, account and password. |
Host addition should fail |
P2 |
negative |
|
||
8 |
Add Baremetal Host by specifying a invalid values for IPMI Ip, account and password. |
Add Baremetal Host by specifying a invalid values for IPMI Ip, account and password. |
Host addition should fail. |
P2 |
negative |
|
||
9 |
Add cluster of 2 Baremetal hosts |
Add cluster of 2 Baremetal hosts |
Cluster of hosts added successfully |
P1 |
functional |
|
||
|
|
|
|
|
|
|
||
|
Configuring and adding a TFTP DHCP PXE server |
|
|
|
|
|
||
10 |
Configure TFTP DHCP PXE server |
1. In Xencenter add Xenserver 6.0.2 host which must be on same L2 switch level as Baremetal hosts. 2. Create Centos 6.3 VM on Xenserver host & configure it with IP in the same subnet of guest ip range. 3. On VM Install CloudStack baremetal agent and run cloud-setup-baremetal. |
TFTP server should be started successfully. |
P1 |
functional |
|
||
11 |
Add a TFTP server to the zone using addBaremetalPxeKickStartServer() |
1. Add a TFTP server to the zone using API addBaremetalPxeKickStartServer() |
TFTP server should get added successfully to the Zone. |
P1 |
functional |
|
||
12 |
Add a TFTP server to the zone using addBaremetalPxeKickStartServer() when the TFTP server is not running. |
1. Add a TFTP server to the zone using addBaremetalPxeKickStartServer() when the TFTP server is not running. |
Should the addition of TPFT server fail ? |
P2 |
negative |
|
||
|
|
|
|
|
|
|
||
|
Configuring DHCP server |
|
|
|
|
|
||
13 |
Configure DHCP server |
Configure VM as DHCP server and configure it to service all the hosts in the pod ip range via API addBaremetalDhcp |
|
P1 |
functional |
|
||
|
|
|
|
|
|
|
||
|
Kickstart Installation. Registering templates. |
|
|
|
|
|
||
14 |
Create Baremetal service offering |
Create Baremetal compute offering with Baremetal host hosttag |
Baremetal compute offering created |
P1 |
functional |
|
||
15 |
Register baremetal template |
Register a template by passing valid values for displaytext,format,hypervisor="Baremetal", ostypeid,url="Kickstart_file_location;template_repo_on_nfs_path",zoneid . |
Template registration should succeed. |
P1 |
functional |
|
||
16 |
Register template with invalid format |
Register a template by passing url with invalid format like only Kickstart_file_location /only template_repo_on_nfs_path /using a different separator instead of ";" like Kickstart_file_location.template_repo_on_nfs_path |
Template registration should fail. |
P2 |
negative |
|
||
17 |
Register template with invalid Kickstart_file_location |
Register a template by passing invalid values for Kickstart_file_location |
Template registration should fail. |
P2 |
negative |
|
||
18 |
Register template with invalid template_repo_on_nfs_path |
Register a template by passing invalid values for template_repo_on_nfs_path |
Template registration should fail. |
P2 |
negative |
|
||
19 |
List all the templates for Baremetal hypervisors. |
1. Register few "Baremetal" templates. 2. List all the templates for Baremetal hypervisors. |
All the templates for Baremetal should be listed. |
P1 |
|
|
||
20 |
Deletion of templates. |
1. Register few "Baremetal" templates. 2. Delete some of the "Baremetal" templates. 3. List all the templates for Baremetal hypervisors. |
Deletion of templates should succeed. All the templates for Baremetal should be listed. This should not include the template that was deleted. |
P1 |
|
|
||
|
|
|
|
|
|
|
||
|
Ping style Installation |
|
|
|
|
|
||
21 |
Install Windows 2008 R2 Server on a server that is identical (CPU, memory, disk, resources) to the servers which will be used as baremetal hosts. Use PING http://ping.windowsdream.com   ; to backup & create image of the template OS onto network Register a template by passing valid values for displaytext,format,hypervisor="Baremetal", ostypeid,url="ping_file_location;template_repo_on_nfs_path",zoneid . |
1. Install Windows 2008 R2 Server on a server 2. Use PING to backup & create image of template OS 3. Register a template by passing valid values for displaytext,format,hypervisor="Baremetal", ostypeid,url="ping_file_location;template_repo_on_nfs_path",zoneid . |
Template registration should succeed. |
P1 |
functional |
|
||
22 |
Register a template by passing url with invalid format like only ping_file_location /only template_repo_on_nfs_path /using a different separator instead of ";" like ping_file_location.template_repo_on_nfs_path |
Register a template by passing url with invalid format like only ping_file_location /only template_repo_on_nfs_path /using a different separator instead of ";" like ping_file_location.template_repo_on_nfs_path |
Template registration should fail. |
P2 |
negative |
|
||
23 |
Register a template with invalid values for ping_file_location |
Register a template by passing invalid values for ping_file_location |
Template registration should fail. |
P2 |
negative |
|
||
|
|
|
|
|
|
|
||
|
Deploying baremetal VM |
|
|
|
|
|
||
24 |
Deploy baremetal VM |
Deploy a VM using a SO with host tag of a Baremetal host using a baremetal template. Steps involved when deploying VM: 1. Program the TFTP server . Add an entry for the MAC address under /var/lib/tftpboot/pexclinux.cfg and program the details of the template to be used. 2. Contact the host using IPMI address and attempt the following: 1. boot device set to PXE 2. Power on the device. This should result in PXE boot. 3. During the time when the device is still being PXE booted , VM status should still be presented as "Starting". 4. Management server will constantly try to reach the security agent on this host using the Ipaddress of the host. Once it is able to reach this host , then we will mark the status of the VM as being "UP" in the management server. |
Vm deployment should succeed. |
P1 |
functional |
|
||
25 |
Deploy a VM on a host by passing a hostname. |
Deploy a VM on a host by passing a hostname. |
Vm deployment should succeed. VM should be accessible using the hostname. |
P2 |
functional |
|
||
26 |
Deploy a VM by passing a disk offering id. |
Deploy a VM by passing a disk offering id. |
VM deployment should fail. |
P2 |
negative |
|
||
29 |
Deploy a VM using userdata |
Deploy a VM using userdata |
Vm deployment should succeed. User should be able to retrieve the userdata from url ?? |
P2 |
|
functional |
|
|
30 |
Deploy a VM when TFTP server is not yet configured in the zone. |
Deploy a VM when TFTP server is not yet configured in the zone. |
Vm deployment should fail. |
P2 |
negative |
|
||
31 |
Deploy a VM when TFTP server is not reachable. |
Deploy a VM when TFTP server is not reachable. |
Vm deployment should fail. |
P2 |
negative |
|
||
32 |
Deploy a VM when DHCP server is not reachable. |
Deploy a VM when DHCP server is not reachable. |
Vm deployment should fail. |
P2 |
negative |
|
||
33 |
Deploy a VM when host is in "Down" state. |
Deploy a VM when host is in "Down" state. |
Vm deployment should fail. |
P2 |
negative |
|
||
34 |
Deploy a VM on a host which has an invalid ipaddress( Ipaddress does not exist in the DHCP server) assigned to it. |
Deploy a VM on a host which has an invalid ipaddress( Ipaddress does not exist in the DHCP server) assigned to it. |
Vm deployment should fail. |
P2 |
negative |
|
||
35 |
Deploy a VM on a host which has an invalid ipaddress ( Ipaddress that existis in the DHCP server but is associated with a different MAC address) assigned to it. |
Deploy a VM on a host which has an invalid ipaddress ( Ipaddress that existis in the DHCP server but is associated with a different MAC address) assigned to it. |
Vm deployment should fail. |
P2 |
negative |
|
||
36 |
Deploy a VM on a host which has an invalid MAC address ( MAC address does not exist in the DHCP server) assigned to it. |
Deploy a VM on a host which has an invalid MAC address ( MAC address does not exist in the DHCP server) assigned to it. |
Vm deployment should fail. |
P2 |
negative |
|
||
37 |
Deploy a VM on a host which has an invalid MAC address ( MAC address that existis in the DHCP server but is associated with a different ip address) assigned to it. |
Deploy a VM on a host which has an invalid MAC address ( MAC address that existis in the DHCP server but is associated with a different ip address) assigned to it. |
Vm deployment should fail. |
P2 |
negative |
|
||
38 |
Deploy a VM on a host which has an invalid ipaddress assigned to it. Edit the ipaddress on the host to a correct ip address. Deploy a VM on this host again. |
Deploy a VM on a host which has an invalid ipaddress assigned to it. Edit the ipaddress on the host to a correct ip address. Deploy a VM on this host again. |
Vm deployment should fail. |
P2 |
negative |
|
||
39 |
Deploy a VM on a host which has an invalid MAC address assigned to it. Edit the MAC address on the host to the correct MAC address. Deploy a VM on this host again. |
Deploy a VM on a host which has an invalid MAC address assigned to it. Edit the MAC address on the host to the correct MAC address. Deploy a VM on this host again. |
Vm deployment should fail. |
P2 |
negative |
|
||
|
|
|
|
|
|
|
||
|
Hosts |
|
|
|
|
|
||
40 |
Force reconnect Host() |
Force reconnect Host() |
|
P1 |
functional |
|
||
41 |
UpdateHost() - Edit host tags |
UpdateHost() - Edit host tags |
|
P1 |
functional |
|
||
42 |
deleteHost() - > Put the host in maintenance and then delete the host |
deleteHost() - > Put the host in maintenance and then delete the host |
|
P1 |
functional |
|
||
43 |
Put the host in maintenance mode |
Put the host in maintenance mode |
|
P1 |
functional |
|
||
44 |
Put the host in maintenance mode and bring the host out of maintenance mode. |
Put the host in maintenance mode and bring the host out of maintenance mode. |
|
P1 |
functional |
|
||
46 |
Power down host |
Power down host |
|
P1 |
functional |
|
||
47 |
Power down host and the power on the host |
Power down host and the power on the host |
|
P1 |
functional |
|
||
48 |
Reboot host |
Reboot host |
|
P1 |
functional |
|
||
49 |
Bring down the network connectivity of the host. |
Bring down the network connectivity of the host. |
|
P1 |
functional |
|
||
50 |
Bring down the network connectivity of the host and then bring the network connectivity back up again. |
Bring down the network connectivity of the host and then bring the network connectivity back up again. |
|
P1 |
functional |
|
||
|
|
|
|
|
|
|
||
|
Allocators |
|
|
|
|
|
||
51 |
Deploy a Vm with a host tag that points to Baremetal host , when there are multiple baremetal hosts with the same host tag. |
Deploy a Vm with a host tag that points to Baremetal host , when there are multiple baremetal hosts with the same host tag. |
|
P1 |
functional |
|
||
52 |
Deploy multiple Vm with a host tag that points to Baremetal host , when there are multiple baremetal hosts with the same host tag. |
Deploy multiple Vm with a host tag that points to Baremetal host , when there are multiple baremetal hosts with the same host tag. |
|
P1 |
functional |
|
||
53 |
Deploy a Vm with a host tag that points to Baremetal host , when there is 1 Vm running in all the baremetal hosts with this host tag. |
Deploy a Vm with a host tag that points to Baremetal host , when there is 1 Vm running in all the baremetal hosts with this host tag. |
|
P1 |
functional |
|
||
54 |
Deploy a Vm with a host tag when there are multiple Baremetal hosts , some with host tag - tag1 and others with host tag -tag2. |
Deploy a Vm with a host tag when there are multiple Baremetal hosts , some with host tag - tag1 and others with host tag -tag2. |
|
P1 |
functional |
|
||
55 |
Deploy a Vm with a host tag that points to Baremetal host , when there is 1 Vm running in all the baremetal hosts with this host tag. Destroy one of the VMs. Try to deploy again. We should be able to deploy the Vm in the host from which the Vm was destroyed. |
Deploy a Vm with a host tag that points to Baremetal host , when there is 1 Vm running in all the baremetal hosts with this host tag. Destroy one of the VMs. Try to deploy again. We should be able to deploy the Vm in the host from which the Vm was destroyed. |
|
P1 |
functional |
|
||
|
|
|
|
|
|
|
||
|
VM life Cycle: |
|
|
|
|
|
||
56 |
Stop a VM that is running on Baremetal host. |
Stop a VM that is running on Baremetal host. |
|
P1 |
functional |
|
||
57 |
Start a VM that is in "stopped" state on Baremetal host. |
Start a VM that is in "stopped" state on Baremetal host. |
|
P1 |
functional |
|
||
58 |
Destroy a VM. |
Destroy a VM. |
|
P1 |
functional |
|
||
60 |
Reboot a VM that is running on Baremetal host. |
Reboot a VM that is running on Baremetal host. |
|
P1 |
functional |
|
||
61 |
Change the Serive Offering of a VM in "Stopped" state. Can we get the VM to start in a different host now by changing the host tags in the new service offering ? |
Change the Serive Offering of a VM in "Stopped" state. Can we get the VM to start in a different host now by changing the host tags in the new service offering ? |
|
P1 |
functional |
|
||
64 |
Update Vm and set userdata for a VM that was deployed with no userdata. |
Update Vm and set userdata for a VM that was deployed with no userdata. |
|
P1 |
functional |
|
||
65 |
Update Vm and set a different userdata for a VM that was deployed with some userdata to begin with. |
Update Vm and set a different userdata for a VM that was deployed with some userdata to begin with. |
|
P1 |
functional |
|
||
66 |
Retrieve userdata of the user Vms. |
Retrieve userdata of the user Vms. |
|
P1 |
functional |
|
||
67 |
Retrieve metadata of the user Vms. |
Retrieve metadata of the user Vms. |
|
P1 |
functional |
|
||
68 |
Migrate Virtual machine() ..API should throw an error in this case. |
Migrate Virtual machine() ..API should throw an error in this case. |
|
P2 |
negative |
|
||
|
|
|
|
|
|
|
||
|
Account |
|
|
|
|
|
||
69 |
Delete an Account which has Vms running in SG. |
Delete an Account which has Vms running in SG. |
|
P1 |
functional |
|
||
|
|
|
|
|
|
|
||
|
Security Groups |
|
|
|
|
|
||
70 |
Deploy a VM by passing a Security Group. |
1.To the default security group, Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1). 2.Create a Security Group SG1. 3. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr2). 4. Deploy a VM by passing Security Group SG1. |
1. VM should be deployed as part of only SG1 not default security group. 2. We should not be able to able access this VM from cidr1. 3. We should be able to able access this VM from cidr2. |
P1 |
functional |
|
||
71 |
Deploy a VM by passing a list of Security Groups. |
1. Create a Security Group SG1. 2. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1). 3. Create a Security Group SG2. 4. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr2). 3. Create a Security Group SG3. 4. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr3). 4. Deploy a VM using all the 3 security groups. |
1. VM should be deployed as part of all 3 SG rules. 2. VM should be accessible from cidr1,cidr2 and cidr3. |
P1 |
functional |
|
||
|
CIDR based Ingress rules |
|
|
|
|
|
||
72 |
Deploy a VM in a Security group which has an ingress rule that allows TCP protocols for a port range for a cidr. |
1.Create a Security Group SG1. 2. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1). 3. Deploy a VM as part of SG1. |
1. VM deployment should succeed. 2. We should be able to access this VM from cidr1 using all ports from 22 -80. 3. We should NOT be able to access this VM from any other ipadress . |
P1 |
functional |
|
||
73 |
Deploy a VM in a Security group which has an ingress rule that allows ICMP protocols for a 1 type and 1 code for a cidr. |
1.Create a Security Group SG1. 2. Add a ICMP ingress rule for any 1 type and 1 code for any ipaddress (cidr1). 3. Deploy a VM as part of SG1. |
1. VM deployment should succeed. 2. Make sure that in iptables the correct type and code for ICMP is programmed. |
P1 |
functional |
|
||
73 |
Deploy Vm in a Security group which has an ingress rule that allows TCP protocols for cidr1. Add an ingress rule to allow ICMP protocols for cidr1 and cidr2. |
1.Create a Security Group SG1. 2. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1). 3. Deploy a VM as part of SG1. 4. Add an ingress rule to allow ICMP protocols for cidr1 and cidr2. |
Before Step4: We should be able to access the VM from cidr1. We should not be able to ping the VM from cidr1 and cidr2. After Step4: We should be able to access the VM from cidr1. We should be able to ping the VM from cidr1 and cidr2. |
P1 |
functional |
|
||
74 |
Deploy Vm in a Security group which has an ingress rule that allows TCP protocols for cidr1 and cidr2. Delete the existing ingress rule for cidr1. |
1.Create a Security Group SG1. 2. Add a TCP ingress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Delete the existing TCP ingress rule for cidr1. |
Before Step4: We should be able to access the VM from cidr1 and cidr2. After Step4: We should NOT be able to access the VM from cidr1. We should be able to access the VM from cidr2. |
P1 |
functional |
|
||
75 |
Deploy Vm in a Security group which has an ingress rule that allows ICMP protocols for cidr1 and cidr2. Delete the existing ingress rule for cidr1. |
1.Create a Security Group SG1. 2. Add a ICMP ingress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Delete the existing ICMP ingress rule for cidr1. |
Before Step4: We should be able to ping the VM from cidr1 and cidr2. After Step4: We should NOT be able to ping the VM from cidr1. We should be able to access the VM from cidr2. |
P1 |
functional |
|
||
76 |
Add Ingress rules when the VM is in stopped state. |
1.Create a Security Group SG1. 2. Add a TCP ingress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Stop this VM. 5. Add a TCP ingress rule for ipaddresses cidr3 in SG1. 6. Start this VM. |
As part of starting the VM , we should see the iptable rules being reprogrammed. We should be able to access the VM from cidr1,cidr2 and cidr3. |
P1 |
functional |
|
||
77 |
Delete an Ingress rules when the VM is in stopped state. |
1.Create a Security Group SG1. 2. Add a TCP ingress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Stop this VM. 5. Delete the existing TCP ingress rule for ipaddresses cidr1 in SG1. 6. Start this VM. |
Before Step4: We should be able to access the VM from cidr1,cidr2. We should NOT be able to access the VM from cidr3. After Step4: As part of starting the VM , we should see the iptable rules being reprogrammed. We should be able to access the VM from cidr1,cidr2 and cidr3. |
P1 |
functional |
|
||
|
Account based Ingress rules |
|
|
|
|
|
||
78 |
Deploy a VM in a Security group which has an ingress rule that allows TCP protocols for a port range for another Security Group - SG2. |
1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy a VM in SG1. |
VM should get deployed successfully. From all the VMs in SG2 , we should be able to access this VM on port 22 - port 80 using TCP protocol. |
P1 |
functional |
|
||
79 |
VM should be accessible using their vm name from any other VM. |
1. Deploy few VM in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy VM with display name in SG1. |
VM should get deployed successfully. From all the VMs in SG2 , we should be able to access this VM using the display name on port 22 - port 80 using TCP protocol. |
P1 |
functional |
|
||
80 |
Deploy a VM in a Security group which has an ingress rule that allows ICMP protocols for a port range for another Security Group - SG2. |
1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a ICMP ingress rules that allows port 22-80 for SG2. 3. Deploy a VM in SG1. |
VM should get deployed successfully. From all the VMs in SG2 , we should be able to PING this VM. |
P1 |
functional |
|
||
81 |
Deploy a VM in a SG that is allowed Ingress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Deploy a VM in the SG2. |
This should result in the new VM's ipaddress being added to the ingress chain of all the Vms that are part of SG1. From the new VM , we should be able to access all the Vms in SG1. |
P1 |
functional |
|
||
82 |
Stop a VM that is in a SG that is allowed Ingress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Stop one of the VMS in SG2. |
This should result in the stopped VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1. |
P1 |
functional |
|
||
83 |
Stop and Start a VM that is in a SG that is allowed Ingress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Stop one of the VMS in SG2. 2. Start this VM. |
After Step1: This should result in the stopped VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1. After Step2: This should result in this VM's ipaddress being added to the ingress chain of all the Vms that are part of SG1. From this VM , we should be able to access all the Vms in SG1. |
P1 |
functional |
|
||
84 |
Destroy a VM that is in a SG that is allowed Ingress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Destroy one of the VMS in SG2. |
This should result in the destroyed VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1. |
P1 |
functional |
|
||
85 |
Restore a destroyed VM that is in a SG that is allowed Ingress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Destroy one of the VMS in SG2. 2. Restore this VM back. |
After Step1: This should result in the destroyed VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1. After Step2: This should result in this VM's ipaddress being added to the ingress chain of all the Vms that are part of SG1. From this VM , we should be able to access all the Vms in SG1. |
P1 |
functional |
|
||
86 |
Reboot a VM that is in a SG that is allowed Ingress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Reboot one of the VMS in SG2. |
After Reboot is successful: From this VM , we should still be able to access all the Vms in SG1. |
P1 |
functional |
|
||
|
CIDR based egress rules |
|
|
|
|
|
||
87 |
Deploy a VM in a Security group which has NO egress rules. |
1.Create a Security Group SG1. 2. Have no egress rules. 3. Deploy a VM as part of SG1. |
1. VM deployment should succeed. 2. From this VM , we should we able to access any ipaddress. No egress traffic should be blocked. |
P1 |
functional |
|
||
88 |
Deploy a VM in a Security group which has an egress rule that allows TCP protocols for a port range for a cidr. |
1.Create a Security Group SG1. 2. Add a TCP egress rule for a port range (22-80) for any ipaddress (cidr1). 3. Deploy a VM as part of SG1. |
1. VM deployment should succeed. 2. From this VM , we should we able to access cidr1 using all ports from 22 -80. 3. From this VM, We should NOT be able to access any other ipadress . |
P1 |
functional |
|
||
89 |
Deploy a VM in a Security group which has an egress rule that allows ICMP protocols for 1 type and 1 code for a cidr. |
1.Create a Security Group SG1. 2. Add a ICMP egress rule for any 1 type and 1 code for any ipaddress (cidr1). 3. Deploy a VM as part of SG1. |
1. VM deployment should succeed. 2. Make sure that in iptables the correct type and code for ICMP is programmed. |
P1 |
functional |
|
||
90 |
Deploy few Vms in a Security group which has an egress rule that allows TCP protocols for cidr1. Add an egress rule to allow ICMP protocols for cidr1 and cidr2. |
1.Create a Security Group SG1. 2. Add a TCP egress rule for a port range (22-80) for any ipaddress (cidr1). 3. Deploy a VM as part of SG1. 4. Add an egress rule to allow ICMP protocols for cidr1 and cidr2. |
Before Step4: From this VM , we should be able to access cidr1. From this VM , we should NOT be able allowed to PING cidr1 and cidr2. After Step4: From this VM , we should be able to access cidr1. From this VM , we should be able allowed to PING cidr1 and cidr2. |
P1 |
functional |
|
||
91 |
Deploy few Vms in a Security group which has an egress rule that allows TCP protocols for cidr1 and cidr2. Delete the existing egress rule for cidr1. |
1.Create a Security Group SG1. 2. Add a TCP egress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Delete the existing TCP egress rule for cidr1. |
Before Step4: From this VM , we should be able to access cidr1 and cidr2. After Step4: From this VM , we should be able to access cidr2.But we should not be able to access cidr1. |
P1 |
functional |
|
||
92 |
Deploy few Vms in a Security group which has an egress rule that allows ICMP protocols for cidr1 and cidr2. Delete the existing egress rule for cidr1. |
1.Create a Security Group SG1. 2. Add a ICMP egress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Delete the existing ICMP egress rule for cidr1. |
Before Step4: From this VM , we should be able to ping cidr1 and cidr2. After Step4: From this VM , we should be able to ping cidr2.But we should not be able to ping cidr2. |
P1 |
functional |
|
||
93 |
Add egress rules when the VM is in stopped state. |
1.Create a Security Group SG1. 2. Add a TCP egress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Stop this VM. 5. Add a TCP egress rule for ipaddresses cidr3 in SG1. 6. Start this VM. |
As part of starting the VM , we should see the iptable rules being reprogrammed. We should be able to access the VM from cidr1,cidr2 and cidr3. |
P1 |
functional |
|
||
94 |
Delete an egress rules when the VM is in stopped state. |
1.Create a Security Group SG1. 2. Add a TCP egress rule for ipaddresses cidr1 and cidr2. 3. Deploy a VM as part of SG1. 4. Stop this VM. 5. Delete the existing TCP egress rule for ipaddresses cidr1 in SG1. 6. Start this VM. |
Before Step4: From this VM , we should be able to access cidr1 and cidr2. From this VM , we should NOT be able to access cidr3. After Step4: From this VM , we should be able to access cidr1,cidr2 and cidr3. |
P1 |
functional |
|
||
|
Account based egress rules |
|
|
|
|
|
||
95 |
Deploy a VM in a Security group which has an egress rule that allows TCP protocols for a port range for another Security Group - SG2. |
1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows port 22-80 for SG1. 3. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2. 4. Deploy a VM in SG2. |
VM should get deployed successfully. From Vms in SG1 , we should be able to access all the Vms in SG2. From Vms in SG1 , we should not be able to access any other Vms (vms that are part of other SG and vms that are part of the same group) |
P1 |
functional |
|
||
96 |
Deploy a VM in a Security group which has an egress rule that allows ICMP protocols for another Security Group - SG2. |
1. Deploy few Vms in Security Group - SG2 that has a ICMP ingress rules that allows SG2. 2. Create a Security Group SG1 that has a ICMP egress rules that allows port 22-80 for SG2. 3. Deploy a VM in SG2. |
VM should get deployed successfully. From all the VMs in SG1 , we should be able to PING all the Vms in SG2. |
P1 |
functional |
|
||
97 |
Stop a VM that is in a SG that is allowed egress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows SG2. 2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Stop one of the VMS in SG2. |
This should result in the stopped VM's ipaddress being removed from the egress chain of all the Vms that are part of SG1. |
P1 |
functional |
|
||
98 |
Stop and Start a VM that is in a SG that is allowed egress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows SG2. 2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Stop one of the VMS in SG2. 2. Start this VM. |
After Step1: This should result in the stopped VM's ipaddress being removed from the egress chain of all the Vms that are part of SG1. After Step2: This should result in this VM's ipaddress being added to the egress chain of all the Vms that are part of SG1. From this VM , we should be able to access all the Vms in SG1. |
P1 |
functional |
|
||
99 |
Destroy a VM that is in a SG that is allowed egress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows SG2. 2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Destroy one of the VMS in SG2. |
This should result in the destroyed VM's ipaddress being removed from the egress chain of all the Vms that are part of SG1. |
P1 |
functional |
|
||
100 |
Reboot a VM that is in a SG that is allowed egress access to another Security Group. |
Pre-Red: 1. Deploy few Vms in Security Group - SG2. 2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2. 3. Deploy few VMs in SG1. Steps: 1. Reboot one of the VMS in SG2. |
After Reboot is successful: From this VM , we should still be able to access all the Vms in SG1. |
P1 |
functional |
|
||
101 |
Deploy a VM in a Security group that allows for all Vms with in the Security Group to communicate with each other |
1. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG1. 2. Deploy few VMs in SG1. |
VM should get deployed successfully. All the Vms on SG1 , should be able to communicate with each other on TCP protocol for port 22-80. |
P1 |
functional |
|
||
102 |
Deploy a VM in a Security group that allows for all Vms with in the Security Group to communicate with each other. This Security Group should also have restricted egress access to few other cidrs. |
1. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG1. 2. Deploy few VMs in SG1. 3. Add an egress rule for cidr1. 4. Add another egress rule for allowing SG1. |
After Step2: All the Vms on SG1 , should be able to communicate with each other on TCP protocol for port 22-80. After Step3: All the Vms on SG1 , should NOT be able to communicate with each other on TCP protocol for port 22-80. All the Vms should be able to access cidr1. All the Vms should NOT be able to access any other ipaddress other than cidr1. After Step4: All the Vms on SG1 , should be able to communicate with each other on TCP protocol for port 22-80. All the Vms should be able to access cidr1. All the Vms should NOT be able to access any other ipaddress other than cidr1. |
P1 |
functional |
|
|
functional
1 Comment
angie shen
Test Execution results for Baremetal test cases attachment