From 92aa3106521941ee7703bf63ba880717eb995ff8 Mon Sep 17 00:00:00 2001 From: ZhaoBo Date: Thu, 24 Nov 2016 19:04:07 +0800 Subject: [PATCH] Fix zaqar spec PEP8 CI check This patch also ignore "queues" setences. Change-Id: If05d8238a1c92b336faab037b656ca5d5bbd3d49 --- specs/backlog/email-notification.rst | 23 +++++---- specs/kilo/fifo-optional.rst | 8 ++-- specs/kilo/storage-capabilities.rst | 57 +++++++++++++++++++---- specs/liberty/policy_support.rst | 6 +-- specs/mitaka/websocket-binary-support.rst | 6 ++- tests/test_title.py | 4 +- 6 files changed, 74 insertions(+), 30 deletions(-) diff --git a/specs/backlog/email-notification.rst b/specs/backlog/email-notification.rst index 7a3f30c..57d1dc2 100644 --- a/specs/backlog/email-notification.rst +++ b/specs/backlog/email-notification.rst @@ -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 diff --git a/specs/kilo/fifo-optional.rst b/specs/kilo/fifo-optional.rst index e1033b7..4b219f9 100644 --- a/specs/kilo/fifo-optional.rst +++ b/specs/kilo/fifo-optional.rst @@ -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. diff --git a/specs/kilo/storage-capabilities.rst b/specs/kilo/storage-capabilities.rst index a9afc99..985e34a 100644 --- a/specs/kilo/storage-capabilities.rst +++ b/specs/kilo/storage-capabilities.rst @@ -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 ============ diff --git a/specs/liberty/policy_support.rst b/specs/liberty/policy_support.rst index 21e5451..84a7082 100644 --- a/specs/liberty/policy_support.rst +++ b/specs/liberty/policy_support.rst @@ -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 diff --git a/specs/mitaka/websocket-binary-support.rst b/specs/mitaka/websocket-binary-support.rst index c0115e3..583d04f 100644 --- a/specs/mitaka/websocket-binary-support.rst +++ b/specs/mitaka/websocket-binary-support.rst @@ -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'} } diff --git a/tests/test_title.py b/tests/test_title.py index 4f221bf..2031c82 100644 --- a/tests/test_title.py +++ b/tests/test_title.py @@ -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)