openstack
/
tempest
Code Issues Proposed changes
tempest/tempest/scenario
History
Bence Romsics 199e022902 Raise renew_delay in TestNetworkBasicOps:test_subnet_details 
Bug #1813198 can be reproduced both in cirros 0.3.5 and 0.4.0 by:

while true
do
    sudo /bin/kill -USR1 $( cat /var/run/udhcpc.$( ip -o addr | awk '/100.109.0.37/ {print $2}' ).pid )
    #sleep .1
done

Where 100.109.0.37 is the original IP of eth0 in cirros and the 'kill'
line basically reproduces how test_subnet_details() renews the dhcp
lease using busybox's udhcpc.

However if you uncomment the very short sleep in that loop, the error
is gone. It seems to me this because the following line in udhcpc:

https://git.busybox.net/busybox/tree/networking/udhcp/dhcpc.c?h=1_23_stable#n1093

Note: CirrOS 0.4.0 uses BusyBox v1.23.2.

That is SIGUSR1 triggers a renew request in udhcpc. Internally udhcpc
goes into RENEW_REQUESTED state. If it receives a 2nd SIGUSR1 signal
while still in that state then it deconfigures the interface briefly
before acquiring a new (many times still the same) address. For us it
means we should not retry renewing the lease too fast, because if we do
the address may get deconfigured leading to bug #1813198.

Note: the call of the deconfig script can be easily confirmed by
modifying it (for example to log something). In cirros it is located
under '/sbin/cirros-dhcpc'. Look for the case handling the 'deconfig'
parameter.

This patch increases the delay in retries.

Change-Id: I9b18ef2d835e02be30b7c557e5c10585722111a0
Closes-Bug: #1813198
 		2019-01-29 21:21:21 +00:00
..
README.rst Fix docs markup consistency 2017-11-21 19:02:54 +09:00
__init__.py add scenario directory 2013-05-17 08:52:22 -04:00
manager.py docs: Fix incorrect docstrings in reStructuredText format 2018-11-21 19:06:43 -06:00
test_aggregates_basic_ops.py Replace list_hypervisors with list_services 2018-04-04 10:28:40 +03:00
test_encrypted_cinder_volumes.py docs: Fix incorrect docstrings in reStructuredText format 2018-11-21 19:06:43 -06:00
test_minimum_basic.py Refresh server data after fip is assigned 2018-02-06 11:17:06 +00:00
test_network_advanced_server_ops.py Check network connectivity of the instance before and after live 2018-11-28 10:32:50 +08:00
test_network_basic_ops.py Raise renew_delay in TestNetworkBasicOps:test_subnet_details 2019-01-29 21:21:21 +00:00
test_network_v6.py Mark network slow test as slow 2018-11-02 08:00:21 +00:00
test_object_storage_basic_ops.py docs: Fix incorrect docstrings in reStructuredText format 2018-11-21 19:06:43 -06:00
test_security_groups_basic_ops.py docs: Fix incorrect docstrings in reStructuredText format 2018-11-21 19:06:43 -06:00
test_server_advanced_ops.py Trivial docstring cleanup in TestServerAdvancedOps 2018-04-25 16:17:03 -04:00
test_server_basic_ops.py Refactor config drive mounting 2018-02-19 10:16:13 -05:00
test_server_multinode.py Move test decorators to common 2017-08-23 17:09:33 +00:00
test_shelve_instance.py Log server console output during create/get timestamp 2018-07-30 22:46:56 +02:00
test_snapshot_pattern.py Log server console output during create/get timestamp 2018-07-30 22:46:56 +02:00
test_stamp_pattern.py Log server console output during create/get timestamp 2018-07-30 22:46:56 +02:00
test_volume_backup_restore.py Add status check for creating volume backup 2018-06-19 01:08:28 +00:00
test_volume_boot_pattern.py Delete snapshot in test_image_defined_boot_from_volume 2018-08-09 03:50:41 +00:00
test_volume_migrate_attached.py Make volume client alias with _latest suffix 2018-08-07 05:33:48 +00:00

README.rst

Tempest Field Guide to Scenario tests

What are these tests?

Scenario tests are "through path" tests of OpenStack function. Complicated setups where one part might depend on completion of a previous part. They ideally involve the integration between multiple OpenStack services to exercise the touch points between them.

Any scenario test should have a real-life use case. An example would be:

  • "As operator I want to start with a blank environment":
    1. upload a glance image
    2. deploy a vm from it
    3. ssh to the guest
    4. create a snapshot of the vm

Why are these tests in Tempest?

This is one of Tempest's core purposes, testing the integration between projects.

Scope of these tests

Scenario tests should always use the Tempest implementation of the OpenStack API, as we want to ensure that bugs aren't hidden by the official clients.

Tests should be tagged with which services they exercise, as determined by which client libraries are used directly by the test.

Example of a good test

While we are looking for interaction of 2 or more services, be specific in your interactions. A giant "this is my data center" smoke test is hard to debug when it goes wrong.

A flow of interactions between Glance and Nova, like in the introduction, is a good example. Especially if it involves a repeated interaction when a resource is setup, modified, detached, and then reused later again.