openstack
/
zaqar-specs
Code Issues Proposed changes

Fix zaqar spec PEP8 CI check 

This patch also ignore "queues" setences.

Change-Id: If05d8238a1c92b336faab037b656ca5d5bbd3d49
This commit is contained in:
ZhaoBo 2016-11-24 19:04:07 +08:00
parent 897bb8c66f
commit 92aa310652
6 changed files with 74 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
specs/backlog/email-notification.rst
View File

@ -32,8 +32,8 @@ notifications.
Proposed change
===============
Add a new task driver under /notification/task, which will leverage the built-in
/usr/sbin/sendmail command to send messages.
Add a new task driver under /notification/task, which will leverage the
built-in /usr/sbin/sendmail command to send messages.
Proposed REST API request looks like::
@ -50,13 +50,15 @@ The email notification driver will support the standard mailto protocol, that
said, such as subject, cc and bcc could be a part of the 'subscriber' attribue.
For example:
mailto:someone@example.com?subject=This%20is%20the%20subject&cc=someone_else@example.com&body=This%20is%20the%20body
mailto:someone@example.com?subject=This%20is%20the%20subject&cc=
someone_else@example.com&body=This%20is%20the%20body
Meanwhile, we can also support those email fields in the 'options' attribute.
And to avoid spam, we can send a confirmation email firstly with a confirm_token,
then by default the subcription is in 'inactive' status, until the email owner
clicked the URL in the confirmation email. The URL will be like below::
And to avoid spam, we can send a confirmation email firstly with a
confirm_token, then by default the subcription is in 'inactive' status, until
the email owner clicked the URL in the confirmation email. The URL will be like
below::
/v2/queues/{queue_name}/subscriptions?subscriber=mailto:fake@gmail.com&confirm_token=22c4f150358e4ed287fa51e050d7f024
@ -68,9 +70,9 @@ Alternatives
------------
From the design/architecture perspective, if we don't have an email driver for
notification, that means we may need a email-sending-as-a-service to achieve the
same goal. It doesn't make much sense to do that given we can easily do that
by leveraging the mailto in Zaqar's notification service.
notification, that means we may need a email-sending-as-a-service to achieve
the same goal. It doesn't make much sense to do that given we can easily do
that by leveraging the mailto in Zaqar's notification service.
Data model impact
-----------------
@ -126,7 +128,8 @@ Testing
=======
* Unit tests
* Functional test, like sending to $(whoami)@$(hostname) and then check with 'mail'.
* Functional test, like sending to $(whoami)@$(hostname) and then check with
'mail'.
* Manual testing
Documentation Impact

8
specs/kilo/fifo-optional.rst
View File

@ -71,11 +71,13 @@ Work Items
----------
* Allow driver to expose what features they support
* Each driver supporst a set of features and this set needs to be accessible from the upper layers
Each driver supporst a set of features and this set needs to be accessible
from the upper layers
* Standardize the *supported* capabilities
* Make a list of supported capabilities
Make a list of supported capabilities
* Add a way to pass capabilities down to the driver
* We can do this when the driver is initialized since we know what the capabilities are at that time.
We can do this when the driver is initialized since we know what the
capabilities are at that time.
* Support both, FIFO and non-FIFO, post methods.

57
specs/kilo/storage-capabilities.rst
View File

@ -14,7 +14,14 @@
Expose storage capabilities
=============================
Flavors allow operators to expose some of the internal storage capabilities without giving the exact details of how the system is configured. As of now, the operators has total control over what capabilities are exposed to the user regardeless on whether these capabilities are indeed guaranteed or valid. A `capability` is a feature that is either specific to the storage or to Zaqar - durable, fifo, in-memory, for example - and they can be enabled/exposed in a per-flavor basis allowing end-users to choose the best flavor for a specific queue.
Flavors allow operators to expose some of the internal storage capabilities
without giving the exact details of how the system is configured. As of now,
the operators has total control over what capabilities are exposed to the user
regardeless on whether these capabilities are indeed guaranteed or valid. A
`capability` is a feature that is either specific to the storage or to
Zaqar - durable, fifo, in-memory, for example - and they can be enabled/exposed
in a per-flavor basis allowing end-users to choose the best flavor for a
specific queue.
https://blueprints.launchpad.net/zaqar/+spec/expose-storage-capabilities
@ -22,9 +29,16 @@ https://blueprints.launchpad.net/zaqar/+spec/expose-storage-capabilities
Problem description
===================
Flavors are very powerful when it comes to give choices to end-users without taking control out from operators. However, there's no way for operators to know what capabilities each storage driver has, which makes this feature completely custom to whatever the operator thinks makes more sense.
Flavors are very powerful when it comes to give choices to end-users without
taking control out from operators. However, there's no way for operators to
know what capabilities each storage driver has, which makes this feature
completely custom to whatever the operator thinks makes more sense.
It's important to support operators on the choice of what features are exposed to the end-users through the API by making it clear which are supported by the drivers that have been deployed. Moreover, this is also important for doing a proper capacity planning based on the use-cases the service is trying to support.
It's important to support operators on the choice of what features are exposed
to the end-users through the API by making it clear which are supported by the
drivers that have been deployed. Moreover, this is also important for doing a
proper capacity planning based on the use-cases the service is trying to
support.
Proposed change
===============
@ -32,7 +46,10 @@ Proposed change
Capabilities
------------
This change request proposes defining a set of internal `capabilities` and a way for storage drivers to expose which capabilities are supported so that operators may know in advance what a flavor would support and what storage drivers they may need.
This change request proposes defining a set of internal `capabilities` and a
way for storage drivers to expose which capabilities are supported so that
operators may know in advance what a flavor would support and what storage
drivers they may need.
The set of internal capabilities includes:
@ -44,7 +61,11 @@ The set of internal capabilities includes:
Exposing Capabilities
---------------------
This capabilities should be exposed by the storage driver iff supported. This spec proposes adding a new class method to the base class called `capabilities` that should return a set with a list of supported `capabilities`. The capabilities returned in this set cannot be custom, which means they must be supported internally.::
This capabilities should be exposed by the storage driver iff supported. This
spec proposes adding a new class method to the base class called `capabilities`
that should return a set with a list of supported `capabilities`. The
capabilities returned in this set cannot be custom, which means they must be
supported internally.::
@six.add_metaclass(abc.ABCMeta)
class DataDriverBase(DriverBase):
@ -58,18 +79,32 @@ This capabilities should be exposed by the storage driver iff supported. This sp
Drivers Load
------------
In addition to the above-mentioned changes, we also need a better way to load drivers based on the capabilities. That is, when drivers are loaded, it's necessary to pass down to the driver the capabilities that have been enabled per-flavor so that the driver itself can be specialized for some capabilities. In most of the cases, loading a driver will end up in always loading the same implementation. However, there are cases - FIFO, for example - where more specialized implementations may be needed depending on the storage. Therefore, instead of *always* loading the `DataDriver`, this spec proposes adding a new `get_driver` function that will let the storage itself load a driver according to the capabilities passed there.::
In addition to the above-mentioned changes, we also need a better way to load
drivers based on the capabilities. That is, when drivers are loaded, it's
necessary to pass down to the driver the capabilities that have been enabled
per-flavor so that the driver itself can be specialized for some capabilities.
In most of the cases, loading a driver will end up in always loading the same
implementation. However, there are cases - FIFO, for example - where more
specialized implementations may be needed depending on the storage. Therefore,
instead of *always* loading the `DataDriver`, this spec proposes adding a new
`get_driver` function that will let the storage itself load a driver according
to the capabilities passed there.::
def get_driver(plane='data', capabilities=None):
...
This means we won't need to register neither `DataDriver`s nor `ControlDriver`s as `entry_points` but just the new `get_driver` function. This will allow storage driver's to expose fewer things as public API's. A variant for the above `get_driver` proposal would be.::
This means we won't need to register neither `DataDriver`s nor `ControlDriver`s
as `entry_points` but just the new `get_driver` function. This will allow
storage driver's to expose fewer things as public API's. A variant for the
above `get_driver` proposal would be.::
def get_driver(base=base.BaseDataDriver, capabilities=None):
...
This way we can avoid giving 'names' to this planes and just ask what we need in terms of 'signature'. However, it makes loading the actual driver a bit more complex and it'll also duplicate some logic across different storage drivers.
This way we can avoid giving 'names' to this planes and just ask what we need
in terms of 'signature'. However, it makes loading the actual driver a bit more
complex and it'll also duplicate some logic across different storage drivers.
Pools and Flavors
-----------------
@ -112,8 +147,10 @@ Work Items
----------
* Define list of internal capabilities and document it
* Add required abstractions to storage drivers to expose the supported capabilities
* Let flavor's pass the capabilities down to the storage driver when it's being loaded.
* Add required abstractions to storage drivers to expose the supported
capabilities
* Let flavor's pass the capabilities down to the storage driver when it's being
loaded.
Dependencies
============

6
specs/liberty/policy_support.rst
View File

@ -22,9 +22,9 @@ Zaqar needs to support policies as well.
Problem description
===================
Presently Zaqar is missing fine-grained permissions for actions. For example, it's
hard to allow one user only can get message from a queue but not be able to
post message to the queue, or something like that.
Presently Zaqar is missing fine-grained permissions for actions. For example,
it's hard to allow one user only can get message from a queue but not be able
to post message to the queue, or something like that.
Proposed change

6
specs/mitaka/websocket-binary-support.rst
View File

@ -153,7 +153,8 @@ Subscription request message example before implementation::
{
'action': 'subscription_create',
'headers': {'Client-ID': 31209ff3-ba03-4cec-b4ca-655f4899f8aa, 'X-Project-ID': superproject},
'headers': {'Client-ID': 31209ff3-ba03-4cec-b4ca-655f4899f8aa,
'X-Project-ID': superproject},
'body': {'queue_name': 'superqueue', 'ttl': 3600}
}
@ -162,7 +163,8 @@ it can also pass ``accept`` parameter explicitly::
{
'action': 'subscription_create',
'headers': {'Client-ID': 31209ff3-ba03-4cec-b4ca-655f4899f8aa, 'X-Project-ID': superproject},
'headers': {'Client-ID': 31209ff3-ba03-4cec-b4ca-655f4899f8aa,
'X-Project-ID': superproject},
'body': {'queue_name': 'superqueue', 'ttl': 3600, 'accept': 'json'}
}

4
tests/test_title.py
View File

@ -61,7 +61,7 @@ class TestTitles(testtools.TestCase):
def _check_lines_wrapping(self, tpl, raw):
for i, line in enumerate(raw.split("\n")):
if "http://" in line or "https://" in line:
if "http://" in line or "https://" in line or "/queues" in line:
continue
self.assertTrue(
len(line) < 80,
@ -108,6 +108,6 @@ class TestTitles(testtools.TestCase):
spec = docutils.core.publish_doctree(data)
titles = self._get_titles(spec)
self._check_titles(filename, titles)
#self._check_lines_wrapping(filename, data)
self._check_lines_wrapping(filename, data)
self._check_no_cr(filename, data)
self._check_trailing_spaces(filename, data)