Add doc8 to pep8 check for glance project

This patch adds a doc8 check of .rst files to the current pep8 check.
It includes fixes to the .rst files that didn't pass the check.

Co-authored-By: Hoang Trung Hieu <hieuht@vn.fujitsu.com>
Change-Id: I5a9299200202576d97760ebf07bceb930888f2d7

HACKING.rst

@@ -12,12 +12,13 @@ glance Specific Commandments
   assertIsInstance(A, B)
 - [G317] Change assertEqual(type(A), B) by optimal assert like
   assertIsInstance(A, B)
-- [G318] Change assertEqual(A, None) or assertEqual(None, A) by optimal assert like
-  assertIsNone(A)
+- [G318] Change assertEqual(A, None) or assertEqual(None, A) by optimal assert
+  like assertIsNone(A)
 - [G319] Validate that debug level logs are not translated
 - [G320] For python 3 compatibility, use six.text_type() instead of unicode()
 - [G327] Prevent use of deprecated contextlib.nested
-- [G328] Must use a dict comprehension instead of a dict constructor with a sequence of key-value pairs
+- [G328] Must use a dict comprehension instead of a dict constructor with
+  a sequence of key-value pairs
 - [G329] Python 3: Do not use xrange.
 - [G330] Python 3: do not use dict.iteritems.
 - [G331] Python 3: do not use dict.iterkeys.

doc/source/admin/controllingservers.rst

@@ -69,7 +69,8 @@ If no configuration file is found, you will see an error, like::
   $> glance-api
   ERROR: Unable to locate any configuration file. Cannot load application glance-api
 
-Here is an example showing how you can manually start the ``glance-api`` server and ``glance-registry`` in a shell.::
+Here is an example showing how you can manually start the ``glance-api`` server
+and ``glance-registry`` in a shell.::
 
   $ sudo glance-api --config-file glance-api.conf --debug &
   jsuh@mc-ats1:~$ 2011-04-13 14:50:12    DEBUG [glance-api] ********************************************************************************
@@ -120,9 +121,9 @@ Here is an example showing how you can manually start the ``glance-api`` server
   root     20012  2.0  0.1  25188 13356 pts/1    S    12:47   0:00 /usr/bin/python /usr/bin/glance-registry glance-registry.conf
   jsuh     20017  0.0  0.0   3368   744 pts/1    S+   12:47   0:00 grep glance
 
-Simply supply the configuration file as the parameter to the ``--config-file`` option
-(the ``etc/glance-api.conf`` and  ``etc/glance-registry.conf`` sample configuration
-files were used in the above example) and then any other options
+Simply supply the configuration file as the parameter to the ``--config-file``
+option (the ``etc/glance-api.conf`` and  ``etc/glance-registry.conf`` sample
+configuration files were used in the above example) and then any other options
 you want to use. (``--debug`` was used above to show some of the debugging
 output that the server shows when starting up. Call the server program
 with ``--help`` to see all available options you can specify on the
@@ -133,9 +134,10 @@ configuration files, see the section entitled
 :ref:`Configuring Glance servers <configuring>`
 
 Note that the server `daemonizes` itself by using the standard
-shell backgrounding indicator, ``&``, in the previous example. For most use cases, we recommend
-using the ``glance-control`` server daemon wrapper for daemonizing. See below
-for more details on daemonization with ``glance-control``.
+shell backgrounding indicator, ``&``, in the previous example.
+For most use cases, we recommend using the ``glance-control`` server daemon
+wrapper for daemonizing. See below for more details on daemonization
+with ``glance-control``.
 
 Using the ``glance-control`` program to start the server
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -150,8 +152,8 @@ meaning that the server program process runs in the background.
 
 To start a Glance server with ``glance-control``, simply call
 ``glance-control`` with a server and the word "start", followed by
-any command-line options you wish to provide. Start the server with ``glance-control``
-in the following way::
+any command-line options you wish to provide. Start the server
+with ``glance-control`` in the following way::
 
   $> sudo glance-control [OPTIONS] <SERVER> start [CONFPATH]
 
@@ -188,13 +190,15 @@ and respawned if necessary, use the following option::
   $ sudo glance-control [service] start --respawn ...
 
 
-Note that this will cause ``glance-control`` itself to remain running. Also note
-that deliberately stopped services are not respawned, neither are rapidly bouncing
-services (where process death occurred within one second of the last launch).
+Note that this will cause ``glance-control`` itself to remain running.
+Also note that deliberately stopped services are not respawned,
+neither are rapidly bouncing services (where process death occurred within
+one second of the last launch).
 
 
-By default, output from glance services is discarded when launched with ``glance-control``.
-In order to capture such output via syslog, use the following option::
+By default, output from glance services is discarded when launched
+with ``glance-control``. In order to capture such output via syslog,
+use the following option::
 
 
   $ sudo glance-control --capture-output ...
@@ -236,6 +240,6 @@ here::
   $> sudo glance-control api reload
   Reloading glance-api (pid 18506) with signal(1)
 
-A reload sends a SIGHUP signal to the master process and causes new configuration
-settings to be picked up without any interruption to the running service (provided
-neither bind_host or bind_port has changed).
+A reload sends a SIGHUP signal to the master process and causes new
+configuration settings to be picked up without any interruption to the
+running service (provided neither bind_host or bind_port has changed).

doc/source/admin/db-sqlalchemy-migrate.rst

@@ -38,7 +38,8 @@ Sync the Database
 
     glance-manage db sync <version> <current_version>
 
-Place a database under migration control and upgrade, creating it first if necessary.
+Place a database under migration control and upgrade,
+creating it first if necessary.
 
 
 Determining the Database Version

doc/source/admin/interoperable-image-import.rst

@@ -59,7 +59,7 @@ task policies unrestricted while not exposing the Tasks API to end
 users.  Thus, the following is the recommended configuration for the
 task-related policies:
 
-.. code-block:: none
+.. code-block:: ini
 
    "get_task": "",
    "get_tasks": "",

doc/source/admin/property-protections.rst

@@ -44,15 +44,15 @@ expression matching a set of properties to be protected.
 
 .. note::
 
-  Section headers must compile to a valid regular expression, otherwise 
+  Section headers must compile to a valid regular expression, otherwise
   glance api service will not start. Regular expressions
   will be handled by python's re module which is PERL like.
 
 Each section describes four key-value pairs, where the key is one of
 ``create/read/update/delete``, and the value is a comma separated list of user
-roles that are permitted to perform that operation in the Glance API. **If any of
-the keys are not specified, then the glance api service will not start
-successfully.**
+roles that are permitted to perform that operation in the Glance API.
+**If any of the keys are not specified, then the glance api service will
+not start successfully.**
 
 In the list of user roles, ``@`` means all roles and ``!`` means no role.
 **If both @ and ! are specified for the same rule then the glance api service
@@ -93,7 +93,8 @@ disabled for all roles.
 If an operation is misspelled or omitted, that operation will be disabled for
 all roles.
 
-Disallowing ``read`` operations will also disallow ``update/delete`` operations.
+Disallowing ``read`` operations will also disallow ``update/delete``
+operations.
 
 A successful HTTP request will return status ``200 OK``. If the user is not
 permitted to perform the requested action, ``403 Forbidden`` will be returned.

doc/source/admin/tasks.rst

@@ -120,8 +120,8 @@ the endpoint to which it belongs. The id is used as a token in request URIs to
 interact with that specific task.
 
 In addition to the usual properties you'd expect (for example, ``created_at``,
-``self``, ``type``, ``status``, ``updated_at``, etc.), tasks have these properties of
-interest:
+``self``, ``type``, ``status``, ``updated_at``, etc.),
+tasks have these properties of interest:
 
 * ``input``: this is defined to be a JSON blob, the exact content of which will
   depend upon the requirements set by the specific cloud deployer.  The intent