add doc8 validation

doc8 is similar to flake8, but for documentation: it's an opinionated
style checker.

  https://github.com/stackforge/doc8

This patch also fixes two violations, regarding maximum line length and
trailing whitespace.

Change-Id: Icdbd360cea149f1af72243a59efedaed504ff336

requirements.txt

@@ -7,3 +7,4 @@ sphinx>=1.1.2,!=1.2.0,<1.3
 testrepository>=0.0.18
 testtools>=0.9.34
 yasfb>=0.5.1
+doc8

specs/juno/audit-support-for-federation.rst

@@ -12,14 +12,14 @@ Audit Support for Keystone Federation
 <https://blueprints.launchpad.net/keystone/+spec/
 audit-support-for-federation>`_
 
-Keystone is expanding its support for federated identity to enable it to have
-a more seamless integration into enterprise environments and to leverage
-existing identity providers. The extra complexity associated with authentication
-and authorization in federated Keystone deployments demands suitable audit
-support to ensure the OpenStack environment is used in a compliant fashion. In
-this blueprint we describe proposed auditing support for Keystone federated
-identity operations using the `DMTF Cloud Auditing Data Federation (CADF) Open
-Standard <http://www.dmtf.org/standards/cadf>`_, and leveraging `PyCADF
+Keystone is expanding its support for federated identity to enable it to have a
+more seamless integration into enterprise environments and to leverage existing
+identity providers. The extra complexity associated with authentication and
+authorization in federated Keystone deployments demands suitable audit support
+to ensure the OpenStack environment is used in a compliant fashion. In this
+blueprint we describe proposed auditing support for Keystone federated identity
+operations using the `DMTF Cloud Auditing Data Federation (CADF) Open Standard
+<http://www.dmtf.org/standards/cadf>`_, and leveraging `PyCADF
 <http://docs.openstack.org/developer/pycadf/>`_.
 
 Problem Description

specs/juno/generic-mapping-federation.rst

@@ -13,10 +13,10 @@ Standardizing the federation process
 
 
 We propose that the federated authentication process be reengineered so that a
-user_id is returned alongside the identity attributes. In addition, the saml2.py
-authentication module should be renamed as mapped.py to denote that it applies
-to all authentication methods which require the asserted identity attributes to
-be mapped into local attributes.
+user_id is returned alongside the identity attributes. In addition, the
+saml2.py authentication module should be renamed as mapped.py to denote that it
+applies to all authentication methods which require the asserted identity
+attributes to be mapped into local attributes.
 
 
 Problem Description
@@ -25,9 +25,10 @@ Problem Description
 The existing federation logic uses `saml2` auth plugin to establish a local
 Keystone identity, by mapping trusted external identity attributes to local
 identity attributes. Now that other federation protocols will be supported by
-Keystone, it makes no sense to apply mapping via a saml2 plugin. Some federation
-authentication protocols already determine the ID of the user, this should be
-leveraged by the protocol specific sub modules and not the mapping engine.
+Keystone, it makes no sense to apply mapping via a saml2 plugin. Some
+federation authentication protocols already determine the ID of the user, this
+should be leveraged by the protocol specific sub modules and not the mapping
+engine.
 
 Proposed Change
 ===============
@@ -41,11 +42,11 @@ In order to resolve the problem the following changes should be made:
 #. The function for extracting attributes should return a user_id among the
    asserted attributes.
 
-Splitting the logic of the Mapped plugin will allow subclassing of the plugin to
-handle protocols which provide attributes in a different way to mod_shib, while
-still enabling reuse of the mapping filter implementation. We can then use the
-correct method name according to the protocol used so that clients can easily
-determine their behaviour.
+Splitting the logic of the Mapped plugin will allow subclassing of the plugin
+to handle protocols which provide attributes in a different way to mod_shib,
+while still enabling reuse of the mapping filter implementation. We can then
+use the correct method name according to the protocol used so that clients can
+easily determine their behaviour.
 
 For instance, a configuration for a SAML2 and an Open ID Connect enabled
 Keystone might look like: ::

specs/juno/hierarchical_multitenancy.rst

@@ -128,12 +128,12 @@ Proposed Change
    * Example:
 
      * The domain_admin_team creates the Dev and Test projects and assigns the
-       role ``project_admin`` to project_admin_user. As their role is inheritable
-       it will have access to their children.
+       role ``project_admin`` to project_admin_user. As their role is
+       inheritable it will have access to their children.
 
-     * As Joe has ``project_admin`` role assignment in Dev project, he can create
-       instances in this project and can create subproject and control quotas
-       to his subprojects. The same thing will happen to Sam in Test.
+     * As Joe has ``project_admin`` role assignment in Dev project, he can
+       create instances in this project and can create subproject and control
+       quotas to his subprojects. The same thing will happen to Sam in Test.
 
      * The user_project_admin can grant/revoke roles to users in its project
        and in its subprojects. A user with a member role can't grant/revoke
@@ -239,8 +239,8 @@ Work Items
    have to implement the following functions: (This change will be made in
    extension OS-INHERIT)
 
-  * A role assignment defined for a project A must be inherited by all the child
-    projects of project A;
+  * A role assignment defined for a project A must be inherited by all the
+    child projects of project A;
   * A role assignment defined for a group X must be inherited by all the child
     projects of that group X;
   * For a project A, list all the inherited roles assignment of A, which will

specs/juno/keystone-to-keystone-federation.rst

@@ -335,9 +335,9 @@ Performance Impact
 The following operations may impact performance:
 
 * Since there could be as many service providers as regions, the catalog may
-  become larger. However this limitation exists today as a catalog can have many
-  endpoints and also become pretty large with the endpoints that a user has
-  access to.
+  become larger. However this limitation exists today as a catalog can have
+  many endpoints and also become pretty large with the endpoints that a user
+  has access to.
 
 * More certificates to validate tokens against.
 

specs/juno/multi-backend-uuids.rst

@@ -328,7 +328,8 @@ The two main impacts on a deployer will be:
     This will purge all mappings
   - ``keystone-manage mapping_purge --domain-name <name>``--
     This will purge all mappings for the named domain
-  - ``keystone-manage mapping_purge --domain-name <name> --local-id <ID> --type <user|group>``--
+  - ``keystone-manage mapping_purge --domain-name <name> --local-id <ID> --type
+    <user|group>``--
     This will purge the mapping for the named local identifier
   - ``keystone-manage mapping_purge --public-id <ID>``--
     This will purge the mapping for the named public ID

specs/keystonemiddleware/implemented/split-middleware-repo.rst

@@ -138,16 +138,16 @@ Work Items
 
 * Create new repo.
 
-* Copy middleware code and tests from python-keystoneclient to new repo using the
-  oslo-incubator graduation utilities to maintain the change history.
+* Copy middleware code and tests from python-keystoneclient to new repo using
+  the oslo-incubator graduation utilities to maintain the change history.
 
-* Copy middleware (used by external services (e.g. ec2token)) code and tests from
-  keystone to the new repo using the oslo-incubator graduation utilities to
-  maintain the change history.
+* Copy middleware (used by external services (e.g. ec2token)) code and tests
+  from keystone to the new repo using the oslo-incubator graduation utilities
+  to maintain the change history.
 
-* Change keystoneclient and Keystone middleware so that it prints out a deprecated
-  message if it's used. This includes updating any deprecation messages to point
-  to the new package.
+* Change keystoneclient and Keystone middleware so that it prints out a
+  deprecated message if it's used. This includes updating any deprecation
+  messages to point to the new package.
 
 * Release an initial version of the keystonemiddleware package (to be performed
   before deprecation updates).

tox.ini

@@ -8,7 +8,9 @@ usedevelop = True
 setenv = VIRTUAL_ENV={envdir}
 install_command = pip install -U {opts} {packages}
 deps = -r{toxinidir}/requirements.txt
-commands = python setup.py testr --slowest --testr-args='{posargs}'
+commands =
+    python setup.py testr --slowest --testr-args='{posargs}'
+    doc8 specs/
 
 [testenv:venv]
 commands = {posargs}