scenario package

Submodules

scenario.manager module

class EncryptionScenarioTest(*args, **kwargs)

Bases: ScenarioTest

Base class for encryption scenario tests

class NetworkScenarioTest(*args, **kwargs)

Bases: ScenarioTest

Base class for network scenario tests.

This class provide helpers for network scenario tests, using the neutron API. Helpers from ancestor which use the nova network API are overridden with the neutron API.

This Class also enforces using Neutron instead of novanetwork. Subclassed tests will be skipped if Neutron is not enabled

class ObjectStorageScenarioTest(*args, **kwargs)

Bases: ScenarioTest

Provide harness to do Object Storage scenario tests.

Subclasses implement the tests that use the methods provided by this class.

class ScenarioTest(*args, **kwargs)

Bases: BaseTestCase

Base class for scenario tests. Uses tempest own clients.

scenario.test_compute_unified_limits module

class ComputeProjectQuotaTest(*args, **kwargs)

Bases: ScenarioTest

The test base class for compute unified limits tests.

Dynamic credentials (unique tenants) are created on a per-class basis, so we test different quota limits in separate test classes to prevent a quota limit update in one test class from affecting a test running in another test class in parallel.

https://docs.openstack.org/tempest/latest/configuration.html#dynamic-credentials

class ServersQuotaTest(*args, **kwargs)

Bases: ComputeProjectQuotaTest

test_server_count_vcpu_memory_disk_quota()

Test idempotent id: 555d8bbf-d2ed-4e39-858c-4235899402d9

scenario.test_dashboard_basic_ops module

class HorizonHTMLParser(*, convert_charrefs=True)

Bases: HTMLParser

class TestDashboardBasicOps(*args, **kwargs)

Bases: BaseTestCase

The test suite for dashboard basic operations

This is a basic scenario test: * checks that the login page is available * logs in as a regular user * checks that the user home page loads without error

test_basic_scenario()

Test idempotent id: 4f8851b1-0e69-482b-b63b-84c6e76f6c80

scenario.test_encrypted_cinder_volumes module

class TestEncryptedCinderVolumes(*args, **kwargs)

Bases: EncryptionScenarioTest

The test suite for encrypted cinder volumes

This test is for verifying the functionality of encrypted cinder volumes.

For both LUKS (v1 & v2) and cryptsetup encryption types, this test performs the following:

• Boots an instance from an image (CONF.compute.image_ref)

• Creates an encryption type (as admin)

• Creates a volume of that encryption type (as a regular user)

• Attaches and detaches the encrypted volume to the instance

test_encrypted_cinder_volumes_cryptsetup()

Test idempotent id: cbc752ed-b716-4717-910f-956cce965722

test_encrypted_cinder_volumes_luks()

Test idempotent id: 79165fb4-5534-4b9d-8429-97ccffb8f86e

LUKs v1 decrypts volume through libvirt.

test_encrypted_cinder_volumes_luksv2()

Test idempotent id: 7abec0a3-61a0-42a5-9e36-ad3138fb38b4

LUKs v2 decrypts volume through os-brick.

scenario.test_instances_with_cinder_volumes module

class TestInstancesWithCinderVolumes(*args, **kwargs)

Bases: ScenarioTest

This is cinder volumes test.

Tests are below: * test_instances_with_cinder_volumes_on_all_compute_nodes

test_instances_with_cinder_volumes_on_all_compute_nodes()

Test idempotent id: d0e3c1a3-4b0a-4b0e-8b0a-4b0e8b0a4b0e

Test instances with cinder volumes launches on all compute nodes

Steps:

1. Create an image

2. Create a keypair

3. Create a bootable volume from the image and of the given volume type

4. Boot an instance from the bootable volume on each available compute node, up to CONF.compute.min_compute_nodes

5. Create a volume using each volume_types_for_data_volume on all available compute nodes, up to CONF.compute.min_compute_nodes. Total number of volumes is equal to compute nodes * len(volume_types_for_data_volume)

6. Attach volumes to the instances

7. Assign floating IP to all instances

8. Configure security group for ssh access to all instances

9. Confirm ssh access to all instances

10. Run write test to all volumes through ssh connection per instance

11. Clean up the sources, an instance, volumes, keypair and image

scenario.test_minimum_basic module

class TestMinimumBasicScenario(*args, **kwargs)

Bases: ScenarioTest

This is a basic minimum scenario test.

These tests below: * across the multiple components * as a regular user * with and without optional parameters * check command outputs

test_minimum_basic_instance_hard_reboot_after_vol_snap_deletion()

Test idempotent id: a8fd48ec-1d01-4895-b932-02321661ec1e

Test compute hard reboot after volume snapshot deleted

Steps: 1. Create image 2. Create keypair 3. Boot instance with keypair and get list of instances 4. Create volume and show list of volumes 5. Attach volume to instance and getlist of volumes 6. Create a snapshot from volume 7. Add IP to instance 8. Create and add security group to instance 9. Check SSH connection to instance 10. Write data timestamp to the attached volume 11. Delete volume snapshot before reboot instance 12. Reboot instance (HARD) 13. Check SSH connection to instance after reboot 14. Verify attached disk data timestamp post instance reboot

test_minimum_basic_scenario()

Test idempotent id: bdbb5441-9204-419d-a225-b4fdbfb1a1a8

This is a basic minimum scenario with multiple components

Steps: 1. Create image 2. Create keypair 3. Boot instance with keypair and get list of instances 4. Create volume and show list of volumes 5. Attach volume to instance and getlist of volumes 6. Add IP to instance 7. Create and add security group to instance 8. Check SSH connection to instance 9. Reboot instance 10. Check SSH connection to instance after reboot

scenario.test_network_advanced_server_ops module

class BaseTestNetworkAdvancedServerOps(*args, **kwargs)

Bases: NetworkScenarioTest

Base class for defining methods used in tests.

class TestNetworkAdvancedServerMigrationWithHost(*args, **kwargs)

Bases: BaseTestNetworkAdvancedServerOps

Check VM connectivity with specifying source and destination hosts:

• Resize an instance by creating server on configured source host

• Migrate server by creating it on configured source host and migrate it

  • Cold Migration

  • Cold Migration with revert

  • Live Migration

test_server_connectivity_cold_migration()

Test idempotent id: 14f0c9e6-79ae-11ee-b962-0242ac120002

test_server_connectivity_cold_migration_revert()

Test idempotent id: 2627789a-79ae-11ee-b962-0242ac120002

test_server_connectivity_live_migration()

Test idempotent id: 1c13933e-79ae-11ee-b962-0242ac120002

test_server_connectivity_resize()

Test idempotent id: 06e23934-79ae-11ee-b962-0242ac120002

class TestNetworkAdvancedServerOps(*args, **kwargs)

Bases: BaseTestNetworkAdvancedServerOps

Check VM connectivity after some advanced instance operations executed:

• Stop/Start an instance

• Reboot an instance

• Rebuild an instance

• Pause/Unpause an instance

• Suspend/Resume an instance

test_server_connectivity_cold_migration()

Test idempotent id: a4858f6c-401e-4155-9a49-d5cd053d1a2f

test_server_connectivity_cold_migration_revert()

Test idempotent id: 25b188d7-0183-4b1e-a11d-15840c8e2fd6

test_server_connectivity_live_migration()

Test idempotent id: 03fd1562-faad-11e7-9ea0-fa163e65f5ce

test_server_connectivity_pause_unpause()

Test idempotent id: 2b2642db-6568-4b35-b812-eceed3fa20ce

test_server_connectivity_reboot()

Test idempotent id: 7b6860c2-afa3-4846-9522-adeb38dfbe08

test_server_connectivity_rebuild()

Test idempotent id: 88a529c2-1daa-4c85-9aec-d541ba3eb699

test_server_connectivity_resize()

Test idempotent id: 719eb59d-2f42-4b66-b8b1-bb1254473967

test_server_connectivity_stop_start()

Test idempotent id: 61f1aa9a-1573-410e-9054-afa557cab021

test_server_connectivity_suspend_resume()

Test idempotent id: 5cdf9499-541d-4923-804e-b9a60620a7f0

scenario.test_network_basic_ops module

class Floating_IP_tuple(floating_ip, server)

Bases: tuple

class TestNetworkBasicOps(*args, **kwargs)

Bases: NetworkScenarioTest

The test suite of network basic operations

This smoke test suite assumes that Nova has been configured to boot VM’s with Neutron-managed networking, and attempts to verify network connectivity as follows:

There are presumed to be two types of networks: tenant and public. A tenant network may or may not be reachable from the Tempest host. A public network is assumed to be reachable from the Tempest host, and it should be possible to associate a public (‘floating’) IP address with a tenant (‘fixed’) IP address to facilitate external connectivity to a potentially unroutable tenant IP address.

This test suite can be configured to test network connectivity to a VM via a tenant network, a public network, or both. If both networking types are to be evaluated, tests that need to be executed remotely on the VM (via ssh) will only be run against one of the networks (to minimize test execution time).

Determine which types of networks to test as follows:

• Configure tenant network checks (via the ‘project_networks_reachable’ key) if the Tempest host should have direct connectivity to tenant networks. This is likely to be the case if Tempest is running on the same host as a single-node devstack installation with IP namespaces disabled.

• Configure checks for a public network if a public network has been configured prior to the test suite being run and if the Tempest host should have connectivity to that public network. Checking connectivity for a public network requires that a value be provided for ‘public_network_id’. A value can optionally be provided for ‘public_router_id’ if tenants will use a shared router to access a public network (as is likely to be the case when IP namespaces are not enabled). If a value is not provided for ‘public_router_id’, a router will be created for each tenant and use the network identified by ‘public_network_id’ as its gateway.

test_connectivity_between_vms_on_different_networks()

Test idempotent id: 1546850e-fbaa-42f5-8b5f-03d8a6a95f15

Test connectivity between VMs on different networks

For a freshly-booted VM with an IP address (“port”) on a given network:

• the Tempest host can ping the IP address.

• the Tempest host can ssh into the VM via the IP address and

  successfully execute the following:

  • ping an external IP address, implying external connectivity.

  • ping an external hostname, implying that dns is correctly

    configured.

  • ping an internal IP address, implying connectivity to another

    VM on the same network.

• Create another network on the same tenant with subnet, create

  an VM on the new network.

  • Ping the new VM from previous VM failed since the new network

    was not attached to router yet.

  • Attach the new network to the router, Ping the new VM from

    previous VM succeed.

test_hotplug_nic()

Test idempotent id: c5adff73-e961-41f1-b4a9-343614f18cfa

Test hotplug network interface

1. Create a network and a VM.

2. Check connectivity to the VM via a public network.

3. Create a new network, with no gateway.

4. Bring up a new interface

5. check the VM reach the new network

test_mtu_sized_frames()

Test idempotent id: b158ea55-472e-4086-8fa9-c64ac0c6c1d0

Validate that network MTU sized frames fit through.

test_network_basic_ops()

Test idempotent id: f323b3ba-82f8-4db7-8ea6-6a895869ec49

Basic network operation test

For a freshly-booted VM with an IP address (“port”) on a given network:

• the Tempest host can ping the IP address. This implies, but

  does not guarantee (see the ssh check that follows), that the VM has been assigned the correct IP address and has connectivity to the Tempest host.

• the Tempest host can perform key-based authentication to an

  ssh server hosted at the IP address. This check guarantees that the IP address is associated with the target VM.

• the Tempest host can ssh into the VM via the IP address and

  successfully execute the following:

  • ping an external IP address, implying external connectivity.

  • ping an external hostname, implying that dns is correctly

    configured.

  • ping an internal IP address, implying connectivity to another

    VM on the same network.

• detach the floating-ip from the VM and verify that it becomes

  unreachable

• associate detached floating ip to a new VM and verify connectivity.

  VMs are created with unique keypair so connectivity also asserts that floating IP is associated with the new VM instead of the old one

Verifies that floating IP status is updated correctly after each change

test_port_security_macspoofing_port()

Test idempotent id: 7c0bb1a2-d053-49a4-98f9-ca1a1d849f63

Tests port_security extension enforces mac spoofing

Neutron security groups always apply anti-spoof rules on the VMs. This allows traffic to originate and terminate at the VM as expected, but prevents traffic to pass through the VM. Anti-spoof rules are not required in cases where the VM routes traffic through it.

The test steps are:

1. Create a new network.

2. Connect (hotplug) the VM to a new network.

3. Check the VM can ping a server on the new network (“peer”)

4. Spoof the mac address of the new VM interface.

5. Check the Security Group enforces mac spoofing and blocks pings via spoofed interface (VM cannot ping the peer).

6. Disable port-security of the spoofed port- set the flag to false.

7. Retest 3rd step and check that the Security Group allows pings via the spoofed interface.

test_preserve_preexisting_port()

Test idempotent id: 759462e1-8535-46b0-ab3a-33aa45c55aaa

Test preserve pre-existing port

Tests that a pre-existing port provided on server boot is not deleted if the server is deleted.

Nova should unbind the port from the instance on delete if the port was not created by Nova as part of the boot request.

We should also be able to boot another server with the same port.

test_router_rescheduling()

Test idempotent id: 2e788c46-fb3f-4ac9-8f82-0561555bea73

Tests that router can be removed from agent and add to a new agent.

1. Verify connectivity

2. Remove router from all l3-agents

3. Verify connectivity is down

4. Assign router to new l3-agent (or old one if no new agent is available)

5. Verify connectivity

test_subnet_details()

Test idempotent id: d8bb918e-e2df-48b2-97cd-b73c95450980

Tests that subnet’s extra configuration details are affecting VMs.

This test relies on non-shared, isolated tenant networks.

NOTE: Neutron subnets push data to servers via dhcp-agent, so any update in subnet requires server to actively renew its DHCP lease.

1. Configure subnet with dns nameserver

2. retrieve the VM’s configured dns and verify it matches the one configured for the subnet.

3. update subnet’s dns

4. retrieve the VM’s configured dns and verify it matches the new one configured for the subnet.

TODO(yfried): add host_routes

any resolution check would be testing either:

• l3 forwarding (tested in test_network_basic_ops)

• Name resolution of an external DNS nameserver - out of scope for Tempest

test_update_instance_port_admin_state()

Test idempotent id: f5dfcc22-45fd-409f-954c-5bd500d7890b

Test to update admin_state_up attribute of instance port

1. Check public and project connectivity before updating

   admin_state_up attribute of instance port to False

2. Check public and project connectivity after updating

   admin_state_up attribute of instance port to False

3. Check public and project connectivity after updating

   admin_state_up attribute of instance port to True

test_update_router_admin_state()

Test idempotent id: 04b9fe4e-85e8-4aea-b937-ea93885ac59f

Test to update admin state up of router

1. Check public connectivity before updating

   admin_state_up attribute of router to False

2. Check public connectivity after updating

   admin_state_up attribute of router to False

3. Check public connectivity after updating

   admin_state_up attribute of router to True

scenario.test_network_qos_placement module

class MinBwAllocationPlacementTest(*args, **kwargs)

Bases: NetworkQoSPlacementTestBase

test_empty_update()

Test idempotent id: 0805779e-e03c-44fb-900f-ce97a790653b

test_migrate_with_qos_min_bw_allocation()

Test idempotent id: 8a98150c-a506-49a5-96c6-73a5e7b04ada

Scenario to migrate VM with QoS min bw allocation in placement

Boot a VM like in test_qos_min_bw_allocation_basic, do the same checks, and * migrate the server * confirm the resize, if the VM state is VERIFY_RESIZE * If the VM goes to ACTIVE state check that allocations are as expected.

test_qos_min_bw_allocation_basic()

Test idempotent id: 78625d92-212c-400e-8695-dd51706858b8

“Basic scenario with QoS min bw allocation in placement.

Steps: * Create prerequisites: ** VLAN type provider network with subnet. ** valid QoS policy with minimum bandwidth rule with min_kbps=1 (This is a simplification to skip the checks in placement for detecting the resource provider tree and inventories, as if bandwidth resource is available 1 kbs will be available). ** invalid QoS policy with minimum bandwidth rule with min_kbs=max integer from placement (this is a simplification again to avoid detection of RP tress and inventories, as placement will reject such big allocation). * Create port with valid QoS policy, and boot VM with that, it should pass. * Create port with invalid QoS policy, and try to boot VM with that, it should fail.

test_qos_min_bw_allocation_update_policy()

Test idempotent id: 79fdaa1c-df62-4738-a0f0-1cff9dc415f6

Test the update of QoS policy on bound port

Related RFE in neutron: #1882804 The scenario is the following: * Have a port with QoS policy and minimum bandwidth rule. * Boot a VM with the port. * Update the port with a new policy with different minimum bandwidth values. * The allocation on placement side should be according to the new rules.

test_qos_min_bw_allocation_update_policy_direction_change()

Test idempotent id: 372b2728-cfed-469a-b5f6-b75779e1ccbe

Test QoS min bw direction change on a bound port

Related RFE in neutron: #1882804 The scenario is the following: * Have a port with QoS policy and minimum bandwidth rule with ingress direction * Boot a VM with the port. * Update the port with a new policy to egress direction in minimum bandwidth rule. * The allocation on placement side should be according to the new rules.

test_qos_min_bw_allocation_update_policy_from_zero()

Test idempotent id: 9cfc3bb8-f433-4c91-87b6-747cadc8958a

Test port without QoS policy to have QoS policy

This scenario checks if updating a port without QoS policy to have QoS policy with minimum_bandwidth rule succeeds only on controlplane, but placement allocation remains 0.

test_qos_min_bw_allocation_update_policy_to_zero()

Test idempotent id: a9725a70-1d28-4e3b-ae0e-450abc235962

Test port with QoS policy to remove QoS policy

In this scenario port with QoS minimum_bandwidth rule update to remove QoS policy results in 0 placement allocation.

test_qos_min_bw_allocation_update_with_multiple_ports()

Test idempotent id: 756ced7f-6f1a-43e7-a851-2fcfc16f3dd7

test_resize_with_qos_min_bw_allocation()

Test idempotent id: c29e7fd3-035d-4993-880f-70819847683f

Scenario to resize VM with QoS min bw allocation in placement.

Boot a VM like in test_qos_min_bw_allocation_basic, do the same checks, and * resize the server with new flavor * confirm the resize, if the VM state is VERIFY_RESIZE * If the VM goes to ACTIVE state check that allocations are as expected.

class NetworkQoSPlacementTestBase(*args, **kwargs)

Bases: NetworkScenarioTest

Base class for Network QoS testing

Base class for testing Network QoS scenarios involving placement resource allocations.

class QoSBandwidthAndPacketRateTests(*args, **kwargs)

Bases: NetworkQoSPlacementTestBase

test_interface_attach_detach()

Test idempotent id: 0393d038-03ad-4844-a0e4-83010f69dabb

test_qos_policy_update_on_bound_port()

Test idempotent id: fdb260e3-caa5-482d-ac7c-8c22adf3d750

test_qos_policy_update_on_bound_port_additional_rule()

Test idempotent id: f5864761-966c-4e49-b430-ac0044b7d658

test_qos_policy_update_on_bound_port_from_null_policy()

Test idempotent id: e6a20125-a02e-49f5-bcf6-894305ee3715

test_qos_policy_update_on_bound_port_to_null_policy()

Test idempotent id: fbbb9c81-ed21-48c3-bdba-ce2361e93aad

test_server_create_delete()

Test idempotent id: 93d1a88d-235e-4b7b-b44d-2a17dcf4e213

test_server_create_no_valid_host_due_to_bandwidth()

Test idempotent id: 915dd2ce-4890-40c8-9db6-f3e04080c6c1

test_server_create_no_valid_host_due_to_packet_rate()

Test idempotent id: 2d4a755e-10b9-4ac0-bef2-3f89de1f150b

test_server_live_migrate()

Test idempotent id: 36ffdb85-6cc2-4cc9-a426-cad5bac8626b

test_server_migrate()

Test idempotent id: bdd0b31c-c8b0-4b7b-b80a-545a46b32abe

test_server_resize()

Test idempotent id: 69d93e4f-0dfc-4d17-8d84-cc5c3c842cd5

test_server_resize_revert()

Test idempotent id: d01d4aee-ca06-4e4e-add7-8a47fe0daf96

scenario.test_network_v6 module

class TestGettingAddress(*args, **kwargs)

Bases: NetworkScenarioTest

Test Summary:

1. Create network with subnets:

   1.1. one IPv4 and 1.2. one or more IPv6 in a given address mode

2. Boot 2 VMs on this network

3. Allocate and assign 2 FIP4

4. Check that vNICs of all VMs gets all addresses actually assigned

5. Each VM will ping the other’s v4 private address

6. If ping6 available in VM, each VM will ping all of the other’s v6 addresses as well as the router’s

test_dhcp6_stateless_from_os()

Test idempotent id: d7e1f858-187c-45a6-89c9-bdafde619a9f

test_dualnet_dhcp6_stateless_from_os()

Test idempotent id: 76f26acd-9688-42b4-bc3e-cd134c4cb09e

test_dualnet_multi_prefix_dhcpv6_stateless()

Test idempotent id: cf1c4425-766b-45b8-be35-e2959728eb00

test_dualnet_multi_prefix_slaac()

Test idempotent id: 9178ad42-10e4-47e9-8987-e02b170cc5cd

test_dualnet_slaac_from_os()

Test idempotent id: b6399d76-4438-4658-bcf5-0d6c8584fde2

test_multi_prefix_dhcpv6_stateless()

Test idempotent id: 7ab23f41-833b-4a16-a7c9-5b42fe6d4123

test_multi_prefix_slaac()

Test idempotent id: dec222b1-180c-4098-b8c5-cc1b8342d611

test_slaac_from_os()

Test idempotent id: 2c92df61-29f0-4eaa-bee3-7c65bef62a43

scenario.test_object_storage_basic_ops module

class TestObjectStorageBasicOps(*args, **kwargs)

Bases: ObjectStorageScenarioTest

test_swift_acl_anonymous_download()

Test idempotent id: 916c7111-cb1f-44b2-816d-8f760e4ea910

This test will cover below steps:

1. Create container

2. Upload object to the new container

3. Change the ACL of the container

4. Check if the object can be download by anonymous user

5. Delete the object and container

test_swift_basic_ops()

Test idempotent id: b920faf1-7b8a-4657-b9fe-9c4512bfb381

Test swift basic ops.

• get swift stat.

• create container.

• upload a file to the created container.

• list container’s objects and assure that the uploaded file is present.

• download the object and check the content

• delete object from container.

• list container’s objects and assure that the deleted file is gone.

• delete a container.

scenario.test_security_groups_basic_ops module

class TestSecurityGroupsBasicOps(*args, **kwargs)

Bases: NetworkScenarioTest

The test suite for security groups

This test suite assumes that Nova has been configured to boot VM’s with Neutron-managed networking, and attempts to verify cross tenant connectivity as follows

ssh:

in order to overcome “ip namespace”, each tenant has an “access point” VM with floating-ip open to incoming ssh connection allowing network commands (ping/ssh) to be executed from within the tenant-network-namespace Tempest host performs key-based authentication to the ssh server via floating IP address

connectivity test is done by pinging destination server via source server ssh connection. success - ping returns failure - ping_timeout reached

multi-node:

Multi-Node mode is enabled when CONF.compute.min_compute_nodes > 1. Tests connectivity between servers on different compute nodes. When enabled, test will boot each new server to different compute nodes.

setup:

for primary tenant:

1. create a network&subnet

2. create a router (if public router isn’t configured)

3. connect tenant network to public network via router

4. create an access point:

   1. a security group open to incoming ssh connection

   2. a VM with a floating ip

5. create a general empty security group (same as “default”, but without rules allowing in-tenant traffic)

tests:

1. _verify_network_details

2. _verify_mac_addr: for each access point verify that (subnet, fix_ip, mac address) are as defined in the port list

3. _test_in_tenant_block: test that in-tenant traffic is disabled without rules allowing it

4. _test_in_tenant_allow: test that in-tenant traffic is enabled once an appropriate rule has been created

5. _test_cross_tenant_block: test that cross-tenant traffic is disabled without a rule allowing it on destination tenant

6. _test_cross_tenant_allow:

   • test that cross-tenant traffic is enabled once an appropriate rule has been created on destination tenant.

   • test that reverse traffic is still blocked

   • test than reverse traffic is enabled once an appropriate rule has been created on source tenant

7. _test_port_update_new_security_group:

   • test that traffic is blocked with default security group

   • test that traffic is enabled after updating port with new security group having appropriate rule

8. _test_multiple_security_groups: test multiple security groups can be associated with the vm

assumptions:

1. alt_tenant/user existed and is different from primary_tenant/user

2. Public network is defined and reachable from the Tempest host

3. Public router can either be:

   • defined, in which case all tenants networks can connect directly to it, and cross tenant check will be done on the private IP of the destination tenant

   or

   • not defined (empty string), in which case each tenant will have its own router connected to the public network

test_boot_into_disabled_port_security_network_without_secgroup()

Test idempotent id: 13ccf253-e5ad-424b-9c4a-97b88a026699

test_cross_tenant_traffic()

Test idempotent id: e79f879e-debb-440c-a7e4-efeda05b6848

test_in_tenant_traffic()

Test idempotent id: 63163892-bbf6-4249-aa12-d5ea1f8f421b

test_multiple_security_groups()

Test idempotent id: d2f77418-fcc4-439d-b935-72eca704e293

Verify multiple security groups and checks that rules

provided in the both the groups is applied onto VM

test_port_security_disable_security_group()

Test idempotent id: 7c811dcc-263b-49a3-92d2-1b4d8405f50c

Verify the default security group rules is disabled.

test_port_update_new_security_group()

Test idempotent id: f4d556d7-1526-42ad-bafb-6bebf48568f6

Verifies the traffic after updating the vm port

With new security group having appropriate rule.

scenario.test_server_advanced_ops module

class TestServerAdvancedOps(*args, **kwargs)

Bases: ScenarioTest

The test suite for server advanced operations

This test case stresses some advanced server instance operations:

• Sequence suspend resume

test_server_sequence_suspend_resume()

Test idempotent id: 949da7d5-72c8-4808-8802-e3d70df98e2c

scenario.test_server_basic_ops module

class TestServerBasicOps(*args, **kwargs)

Bases: ScenarioTest

The test suite for server basic operations

This smoke test case follows this basic set of operations:

• Create a keypair for use in launching an instance

• Create a security group to control network access in instance

• Add simple permissive rules to the security group

• Launch an instance

• Perform ssh to instance

• Verify metadata service

• Verify metadata on config_drive

• Terminate the instance

test_server_basic_ops()

Test idempotent id: 7fff3fb3-91d8-4fd0-bd7d-0204f1f180ba

scenario.test_server_multinode module

class TestServerMultinode(*args, **kwargs)

Bases: ScenarioTest

This is a set of tests specific to multinode testing.

test_schedule_to_all_nodes()

Test idempotent id: 9cecbe35-b9d4-48da-a37e-7ce70aa43d30

scenario.test_server_volume_attachment module

class BaseAttachmentTest(*args, **kwargs)

Bases: ScenarioTest

class TestServerVolumeAttachScenarioOldVersion(*args, **kwargs)

Bases: BaseAttachmentTest

test_old_versions_reject()

Test idempotent id: 6f4d2144-99f4-495c-8b0b-c6a537971418

class TestServerVolumeAttachmentScenario(*args, **kwargs)

Bases: BaseAttachmentTest

Test server attachment behaviors

This tests that volume attachments to servers may not be removed directly and are only allowed through the compute service (bug #2004555).

test_server_detach_rules()

Test idempotent id: be615530-f105-437a-8afe-ce998c9535d9

Test that various methods of detaching a volume honors the rules

scenario.test_shelve_instance module

class TestShelveInstance(*args, **kwargs)

Bases: ScenarioTest

This test shelves then unshelves a Nova instance

The following is the scenario outline:

• boot an instance and create a timestamp file in it

• shelve the instance

• unshelve the instance

• check the existence of the timestamp file in the unshelved instance

• check the existence of the timestamp file in the unshelved instance, after a cold migrate

test_cold_migrate_unshelved_instance()

Test idempotent id: 1295fd9e-193a-4cf8-b211-55358e021bae

test_shelve_instance()

Test idempotent id: 1164e700-0af0-4a4c-8792-35909a88743c

test_shelve_volume_backed_instance()

Test idempotent id: c1b6318c-b9da-490b-9c67-9339b627271f

scenario.test_snapshot_pattern module

class TestSnapshotPattern(*args, **kwargs)

Bases: ScenarioTest

This test is for snapshotting an instance and booting with it.

The following is the scenario outline:

• boot an instance and create a timestamp file in it

• snapshot the instance

• add version metadata to the snapshot image

• boot a second instance from the snapshot

• check the existence of the timestamp file in the second instance

• snapshot the instance again

test_snapshot_pattern()

Test idempotent id: 608e604b-1d63-4a82-8e3e-91bc665c90b4

scenario.test_stamp_pattern module

class TestStampPattern(*args, **kwargs)

Bases: ScenarioTest

The test suite for both snapshoting and attaching of volume

This test is for snapshotting an instance/volume and attaching the volume created from snapshot to the instance booted from snapshot. The following is the scenario outline: 1. Boot an instance “instance1” 2. Create a volume “volume1” 3. Attach volume1 to instance1 4. Create a filesystem on volume1 5. Mount volume1 6. Create a file which timestamp is written in volume1 7. Unmount volume1 8. Detach volume1 from instance1 9. Get a snapshot “snapshot_from_volume” of volume1 10. Get a snapshot “snapshot_from_instance” of instance1 11. Boot an instance “instance2” from snapshot_from_instance 12. Create a volume “volume2” from snapshot_from_volume 13. Attach volume2 to instance2 14. Check the existence of a file which created at 6. in volume2

test_stamp_pattern()

Test idempotent id: 10fd234a-515c-41e5-b092-8323060598c5

scenario.test_unified_limits module

class ImageQuotaTest(*args, **kwargs)

Bases: ScenarioTest

test_image_count_quota()

Test idempotent id: 9b74fe24-183b-41e6-bf42-84c2958a7be8

test_image_count_uploading_quota()

Test idempotent id: b103788b-5329-4aa9-8b0d-97f8733460db

test_image_size_quota()

Test idempotent id: 05e8d064-c39a-4801-8c6a-465df375ec5b

test_image_stage_quota()

Test idempotent id: fc76b8d9-aae5-46fb-9285-099e37f311f7

scenario.test_volume_backup_restore module

class TestVolumeBackupRestore(*args, **kwargs)

Bases: ScenarioTest

Test cinder backup and restore

This testcase verifies content preservation after backup and restore operations by booting a server from a restored backup and check the connectivity to it.

The following is the scenario outline: 1. Create volume from image. 2. Create a backup for the volume. 3. Restore the backup. 4. Boot a server from the restored backup. 5. Create a floating ip. 6. Check server connectivity.

test_volume_backup_restore()

Test idempotent id: 2ce5e55c-4085-43c1-98c6-582525334ad7

scenario.test_volume_boot_pattern module

class TestVolumeBootPattern(*args, **kwargs)

Bases: EncryptionScenarioTest

test_boot_server_from_encrypted_volume_luks()

Test idempotent id: cb78919a-e553-4bab-b73b-10cf4d2eb125

LUKs v1 decrypts volume through libvirt.

test_boot_server_from_encrypted_volume_luksv2()

Test idempotent id: 5ab6100f-1b31-4dd0-a774-68cfd837ef77

LUKs v2 decrypts volume through os-brick.

test_create_server_from_volume_snapshot()

Test idempotent id: 05795fb2-b2a7-4c9f-8fac-ff25aedb1489

test_image_defined_boot_from_volume()

Test idempotent id: 36c34c67-7b54-4b59-b188-02a2f458a63b

test_volume_boot_pattern()

Test idempotent id: 557cd2c2-4eb8-4dce-98be-f86765ff311b

This test case attempts to reproduce the following steps:

• Create in Cinder some bootable volume importing a Glance image

• Boot an instance from the bootable volume

• Write content to the volume

• Delete an instance and Boot a new instance from the volume

• Check written content in the instance

• Create a volume snapshot while the instance is running

• Boot an additional instance from the new snapshot based volume

• Check written content in the instance booted from snapshot

scenario.test_volume_migrate_attached module

class TestVolumeMigrateRetypeAttached(*args, **kwargs)

Bases: ScenarioTest

This test case attempts to reproduce the following steps:

• Create 2 volume types representing 2 different backends

• Create in Cinder some bootable volume importing a Glance image using

• volume_type_1

• Boot an instance from the bootable volume

• Write to the volume

• Perform a cinder retype –on-demand of the volume to type of backend #2

• Check written content of migrated volume

• Check the type of the volume has been updated.

• Check the volume is still in-use and the migration was successful.

• Check that the same volume is attached to the instance.

test_volume_migrate_attached()

Test idempotent id: fe47b1ed-640e-4e3b-a090-200e25607362

test_volume_migrate_attached_data_volume()

Test idempotent id: 1b8661cb-db93-4110-860b-201295027b78

test_volume_retype_attached()

Test idempotent id: deadd2c2-beef-4dce-98be-f86765ff311b

test_volume_retype_attached_data_volume()

Test idempotent id: 122e070c-a5b2-470c-af2b-81e9dbefb9e8

Module contents