Fix RST building
Specs repos now build with tox -e docs and this fails since warnings are treated as errors. Fix issues, see below for details. tox -e docs fails with: 1) queens/remove-pool-group-from-zaqar.rst:402: WARNING: Inline emphasis start-string without end-string. Fix RST syntax. 2) queens/support-md5-of-body.rst:: WARNING: document isn't included in any toctree Include document in toctree. 3) rocky/queue-filter-support.rst:38: WARNING: Literal block expected; none found. Fixed RST. 4) rocky/remove-format-constraint-of-client-id.rst:13: WARNING: Title overline too short. Fixed RST. 5) rocky/remove-format-constraint-of-client-id.rst:37: ERROR: Unexpected indentation. Fixed RST. 6) rocky/subscription-filtering-tags.rst:82: WARNING: Bullet list ends without a blank line; unexpected unindent. Fixed RST. Change-Id: Ide32b348d68e35f8f531c30ddae680d085553b68
This commit is contained in:
Andreas Jaeger
parent
00e6ac6008
commit
b5e14a0e42
|
|
@ -10,3 +10,4 @@
|
|||
support-more-backoff-functions
|
||||
delayed-queues
|
||||
remove-pool-group-from-zaqar
|
||||
support-md5-of-body
|
||||
|
|
|
|||
|
|
@ -399,12 +399,12 @@ flavor in the pool API. This can be compatible with the old way.
|
|||
|
||||
#. Old Way:
|
||||
|
||||
*. configure group in pool API and in flavor API;
|
||||
* configure group in pool API and in flavor API;
|
||||
|
||||
#. New Way:
|
||||
|
||||
*. configure pool_list in flavor API
|
||||
*. add a pool to flavor:
|
||||
* configure pool_list in flavor API
|
||||
* add a pool to flavor:
|
||||
|
||||
#. method one: update pool_list in flavor API
|
||||
#. method two: config a pool with the flavor in pool API.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Proposed change
|
|||
When queue listing, we add filter option in query string parameters
|
||||
like this ::
|
||||
|
||||
GET /v2/queues?key1=value1&key2=value2&name=value3
|
||||
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.
|
||||
|
|
@ -44,8 +44,9 @@ to user.
|
|||
|
||||
API Impact
|
||||
-----------
|
||||
Lists queues
|
||||
GET: /v2/queues?key1=value1&key2=value2
|
||||
Lists queues::
|
||||
|
||||
GET: /v2/queues?key1=value1&key2=value2
|
||||
|
||||
RESPONSE CODE: 200
|
||||
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@
|
|||
For help with syntax, see http://sphinx-doc.org/rest.html
|
||||
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
====================================
|
||||
=====================================
|
||||
Remove format constraint of client id
|
||||
====================================
|
||||
=====================================
|
||||
|
||||
https://blueprints.launchpad.net/zaqar/+spec/remove-format-constraint-of-client-id
|
||||
|
||||
|
|
@ -31,15 +31,15 @@ user id in LDAP as client id, but Zaqar doesn't allow this now.
|
|||
|
||||
Proposed change
|
||||
===============
|
||||
* Add Three config options::
|
||||
* Add Three config options:
|
||||
|
||||
# 'client_id_uuid_safe': Defines the format of client id, the value could be
|
||||
"strict" or "off". "strict" means the format of client id must be uuid,
|
||||
"off" means the restriction be removed. The default value is 'strict'.
|
||||
# 'min_length_client_id': Defines the minimum length of client id if remove
|
||||
the uuid restriction. Default value is 10.
|
||||
# 'max_length_client_id': Defines the maximum length of client id if
|
||||
remove the uuid restriction. Default value is 36.
|
||||
#. 'client_id_uuid_safe': Defines the format of client id, the value could be
|
||||
"strict" or "off". "strict" means the format of client id must be uuid,
|
||||
"off" means the restriction be removed. The default value is 'strict'.
|
||||
#. 'min_length_client_id': Defines the minimum length of client id if remove
|
||||
the uuid restriction. Default value is 10.
|
||||
#. 'max_length_client_id': Defines the maximum length of client id if
|
||||
remove the uuid restriction. Default value is 36.
|
||||
|
||||
* Will change the method 'require_client_id' in wsgi/helpers.py to support
|
||||
validating the different format of client id.
|
||||
|
|
|
|||
|
|
@ -79,20 +79,21 @@ Finally, zaqar decides which subscribers the message should be sent to
|
|||
according to the following rules:
|
||||
|
||||
* If the subscriber does not have any filter_policies, all messages will be
|
||||
sent to the subscriber.
|
||||
sent to the subscriber.
|
||||
|
||||
* If the message does not contain any filter_policies, it will not be sent to
|
||||
the subscriber which has filter_policies.
|
||||
* If the message does not contain any filter_policies, it will not be
|
||||
sent to the subscriber which has filter_policies.
|
||||
|
||||
* If the message and the subscriber's filter_policies have intersecting
|
||||
collections, the message will be sent to the subscriber.
|
||||
collections, the message will be sent to the subscriber.
|
||||
|
||||
* If the message and the subscriber both have filter_policies, but there is no
|
||||
intersection set, no message will be sent to the subscriber.
|
||||
* If the message and the subscriber both have filter_policies, but
|
||||
there is no intersection set, no message will be sent to the
|
||||
subscriber.
|
||||
|
||||
* The relationship of the content in `order_placed` is *or*, it means that the
|
||||
message will be sent to the subscriptions that match anyone filters in
|
||||
`order_placed`.
|
||||
* The relationship of the content in `order_placed` is *or*, it means
|
||||
that the message will be sent to the subscriptions that match anyone
|
||||
filters in `order_placed`.
|
||||
|
||||
Drawbacks
|
||||
---------
|
||||
|
|
@ -136,4 +137,4 @@ None
|
|||
References
|
||||
==========
|
||||
|
||||
[1] https://docs.aws.amazon.com/sns/latest/dg/message-filtering.html
|
||||
[1] https://docs.aws.amazon.com/sns/latest/dg/message-filtering.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue