Browse Source

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
changes/54/580054/5
Vu Cong Tuan 4 years ago
parent
commit
0eacde7e30
  1. 3
      .gitignore
  2. 3
      .stestr.conf
  3. 7
      .testr.conf
  4. 1
      requirements.txt
  5. 11
      specs/queens/delayed-queues.rst
  6. 33
      specs/queens/support-md5-of-body.rst
  7. 23
      specs/rocky/queue-filter-support.rst
  8. 10
      tox.ini

3
.gitignore vendored

@ -26,6 +26,7 @@ pip-log.txt
.tox
nosetests.xml
.testrepository
.stestr/
# Translations
*.mo
@ -48,4 +49,4 @@ ChangeLog
# Editors
*~
.*.swp
.*.swp

3
.stestr.conf

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

7
.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

1
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

11
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:

33
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.

23
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
-----------

10
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

Loading…
Cancel
Save