Switch to stestr

According to Openstack summit session [1],
stestr is maintained project to which all Openstack projects should migrate.
Let's switch to stestr as other projects have already moved to it.

[1] https://etherpad.openstack.org/p/YVR-python-pti

Change-Id: I47130ea63d4427074bf51957032c89c55f7a8dcf

.gitignore

@@ -26,6 +26,7 @@ pip-log.txt
 .tox
 nosetests.xml
 .testrepository
+.stestr/
 
 # Translations
 *.mo

.stestr.conf

@@ -0,0 +1,3 @@
+[DEFAULT]
+test_path=./tests
+top_dir=./

.testr.conf

@@ -1,7 +0,0 @@
-[DEFAULT]
-test_command=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
-             OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
-             OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
-             ${PYTHON:-python} -m subunit.run discover -t ./ . $LISTOPT $IDOPTION
-test_id_option=--load-list $IDFILE
-test_list_option=--list

requirements.txt

@@ -4,4 +4,5 @@ sphinx>=1.1.2,<1.2
 yasfb>=0.5.1
 testrepository>=0.0.18
 testtools>=0.9.34
+stestr>=2.0.0
 flake8

specs/queens/delayed-queues.rst

@@ -50,7 +50,8 @@ Basically, there are 3 scenarios:
 1. Normal message sent to delayed queue
 
    If a normal message without ``delay`` attribute sent to a delayed queue,
-   then the message will use the queue's default delay ``_default_message_delay``.
+   then the message will use the queue's default delay
+   ``_default_message_delay``.
 
 2. Message with attribute ``delay`` sent to delayed queue
 
@@ -62,10 +63,10 @@ Basically, there are 3 scenarios:
 
    A normal queue is a queue with the ``_default_message_delay`` value of 0.
    Whether the message is a normal message or a message with a ``delay``
-   attribute, it will not have a delay feature when it is sent to the normal queue.
-   Zaqar does not perform conditional filtering on the ``delay`` attribute
-   when get/claim messages. This means the delay feature does not affect the
-   performance of normal queue.
+   attribute, it will not have a delay feature when it is sent to the normal
+   queue. Zaqar does not perform conditional filtering on the ``delay``
+   attribute when get/claim messages. This means the delay feature does not
+   affect the performance of normal queue.
 
 Specific implementation steps:
 

specs/queens/support-md5-of-body.rst

@@ -34,28 +34,31 @@ Proposed change
 
 When user claim or get the messages, the checksum will be returned with message
 body together, So user can use it to verify that the message body is correct.
-Currently zaqar only support the checksum of the non-URL-encoded message body based
-on MD5 digests. We may support other algorithms in future versions, including SHA1,
-sha256, sha512, and so on. So, It is necessary to change the following:
+Currently zaqar only support the checksum of the non-URL-encoded message body
+based on MD5 digests. We may support other algorithms in future versions,
+including SHA1, sha256, sha512, and so on. So, It is necessary to change
+the following:
 
-1. Add new property named ``checksum`` for message. This property is a string type.
+1. Add new property named ``checksum`` for message. This property is
+   a string type.
 
-   When you send a message to queue, Zaqar will use the default checksum algorithm
-   MD5 to calculate the ``checksum`` value of the non-URL-encoded message body.
-   Finally Zaqar will store the value on the backend. Now the backend Mongodb,
-   Redis and Swift can be supported.
+   When you send a message to queue, Zaqar will use the default checksum
+   algorithm MD5 to calculate the ``checksum`` value of the non-URL-encoded
+   message body. Finally Zaqar will store the value on the backend.
+   Now the backend Mongodb, Redis and Swift can be supported.
 
-2. Return the property ``checksum`` for message when user claims or gets the message.
+2. Return the property ``checksum`` for message when user claims or gets
+   the message.
 
-   When user gets or claims the message, The API will return the k-v pair of ``checksum``
-   in the body of the message. The user can then use this value to verify that the
-   body of the newly retrieved message is correct or not.
+   When user gets or claims the message, The API will return the k-v pair of
+   ``checksum`` in the body of the message. The user can then use this value to
+   verify that the body of the newly retrieved message is correct or not.
 
 3. This feature is backward compatible.
 
-   For old messages that do not have the checksum attribute, the checksum will return
-   ``None`` for both ``claim`` and ``get`` operation. This feature will also transit
-   smoothly as the old messages gradually expire.
+   For old messages that do not have the checksum attribute, the checksum will
+   return ``None`` for both ``claim`` and ``get`` operation. This feature will
+   also transit smoothly as the old messages gradually expire.
 
 4. Add new data model for message body and queue on different backend.
 

specs/rocky/queue-filter-support.rst

@@ -16,28 +16,31 @@ Queue filter support
 
 https://blueprints.launchpad.net/zaqar/+spec/queue-filter-support
 
-Metadata is a group of key-value pairs that belong to a queue. When a queue is created,
-the user who creates the queue can add the metadata {"keyx": "valuex"} to distinguish it.
-It is necessary for zaqar to support the function of queue filter so that Users can select
-the queue by the specified key-value of metadata.In this blueprints, we will also add queue
-filter by name.
+Metadata is a group of key-value pairs that belong to a queue. When a queue is
+created, the user who creates the queue can add the metadata {"keyx": "valuex"}
+to distinguish it. It is necessary for zaqar to support the function of queue
+filter so that Users can select the queue by the specified key-value of
+metadata. In this blueprints, we will also add queue filter by name.
 
 
 Problem description
 ===================
 
-Zaqar doesn't support queue filter when queue listing, we may add this feature now.
+Zaqar doesn't support queue filter when queue listing,
+we may add this feature now.
 
 
 Proposed change
 ===============
-When queue listing, we add filter option in query string parameters like this ::
+When queue listing, we add filter option in query string parameters
+like this ::
 
 GET /v2/queues?key1=value1&key2=value2&name=value3
 
-If metadata of queue and name is consistent with the filter, the queues will be listed to
-the user, otherwise the queue will be filtered.
-If filter option is enabled, the metadata of the queue will be returned to user.
+If metadata of queue and name is consistent with the filter, the queues will be
+listed to the user, otherwise the queue will be filtered.
+If filter option is enabled, the metadata of the queue will be returned
+to user.
 
 API Impact
 -----------

tox.ini

@@ -10,7 +10,7 @@ setenv =
    VIRTUAL_ENV={envdir}
 deps = -r{toxinidir}/requirements.txt
        -r{toxinidir}/test-requirements.txt
-commands = python setup.py testr --slowest --testr-args='{posargs}'
+commands = stestr run --slowest {posargs}
 
 [testenv:venv]
 commands = {posargs}
@@ -26,7 +26,13 @@ deps =
 commands = sphinx-build -b spelling doc/source doc/build/spelling
 
 [testenv:cover]
-commands = python setup.py testr --coverage --testr-args='{posargs}'
+setenv =
+    PYTHON=coverage run --source specs --parallel-mode
+commands =
+    stestr run '{posargs}'
+    coverage combine
+    coverage html -d cover
+    coverage xml -o cover/coverage.xml
 
 [testenv:pep8]
 commands = flake8