Use doc8 check

doc8 is a linter for documents and used in openstack-manuals.
It is better to enforce document linters for simple checking.

The current rules are really simple like:
- line length check (80 chars)
- new line at the end of file

Change-Id: I3810df521068ffc97e25a5fc56b72397bf9783bc

doc/source/configuration/branding.rst

@@ -113,9 +113,9 @@ Login
 Login Splash Page
 ~~~~~~~~~~~~~~~~~
 
-The login splash page now uses a standard Bootstrap panel in its implementation.
+The login splash page now uses a standard Bootstrap panel in its
-See the **Panels** section in your variables file to variables to easily
+implementation. See the **Panels** section in your variables file to variables
-customize.
+to easily customize.
 
 Modal Login
 ~~~~~~~~~~~

doc/source/configuration/customizing.rst

@@ -46,27 +46,29 @@ This allows for common site-customization requirements such as:
 * Changing the names of dashboards and panels.
 * Re-ordering panels within a dashboard or panel group.
 
-Default Horizon panels are loaded based upon files within the openstack_dashboard/enabled/
+Default Horizon panels are loaded based upon files within the
-folder.  These files are loaded based upon the filename order, with space left for more
+openstack_dashboard/enabled/ folder. These files are loaded based upon the
-files to be added.  There are some example files available within this folder, with the
+filename order, with space left for more files to be added. There are some
-.example suffix added.  Developers and deployers should strive to use this method of
+example files available within this folder, with the .example suffix
-customization as much as possible, and support for this is given preference over more
+added. Developers and deployers should strive to use this method of
-exotic methods such as monkey patching and overrides files.
+customization as much as possible, and support for this is given preference
+over more exotic methods such as monkey patching and overrides files.
 
 .. _horizon-customization-module:
 
 Horizon customization module (overrides)
 ========================================
 
-Horizon has a global overrides mechanism available to perform customizations that are not
+Horizon has a global overrides mechanism available to perform customizations
-yet customizable via configuration settings.  This file can perform monkey patching and
+that are not yet customizable via configuration settings. This file can perform
-other forms of customization which are not possible via the enabled folder's customization
+monkey patching and other forms of customization which are not possible via the
-method.
+enabled folder's customization method.
 
-This method of customization is meant to be available for deployers of Horizon, and use of
+This method of customization is meant to be available for deployers of Horizon,
-this should be avoided by Horizon plugins at all cost.  Plugins needing this level of
+and use of this should be avoided by Horizon plugins at all cost. Plugins
-monkey patching and flexibility should instead look for changing their __init__.py file
+needing this level of monkey patching and flexibility should instead look for
-and performing customizations through other means.
+changing their __init__.py file and performing customizations through other
+means.
 
 To specify the python module containing your modifications, add the key
 ``customization_module`` to your ``HORIZON_CONFIG`` dictionary in
@@ -198,12 +200,12 @@ Customize Angular dashboards
 ============================
 
 In Angular, you may write a plugin to extend certain features. Two components
-in the Horizon framework that make this possible are the extensibility service and
+in the Horizon framework that make this possible are the extensibility service
-the resource type registry service. The ``extensibleService`` allows certain Horizon
+and the resource type registry service. The ``extensibleService`` allows
-elements to be extended dynamically, including add, remove, and replace. The
+certain Horizon elements to be extended dynamically, including add, remove, and
-``resourceTypeRegistry`` service provides methods to set and get information
+replace. The ``resourceTypeRegistry`` service provides methods to set and get
-pertaining to a resource type object. We use Heat type names like ``OS::Glance::Image``
+information pertaining to a resource type object. We use Heat type names like
-as our reference name.
+``OS::Glance::Image`` as our reference name.
 
 Some information you may place in the registry include:
 
@@ -213,7 +215,8 @@ Some information you may place in the registry include:
 * URL paths to detail view or detail drawer
 * Property information like labels or formatting for property values
 
-These properties in the registry use the extensibility service (as of Newton release):
+These properties in the registry use the extensibility service (as of Newton
+release):
 
 * globalActions
 * batchActions
@@ -224,8 +227,8 @@ These properties in the registry use the extensibility service (as of Newton rel
 
 Using the information from the registry, we can build out our dashboard panels.
 Panels use the high-level directive ``hzResourceTable`` that replaces common
-templates so we do not need to write boilerplate HTML and controller code.
+templates so we do not need to write boilerplate HTML and controller code. It
-It gives developers a quick way to build a new table or change an existing table.
+gives developers a quick way to build a new table or change an existing table.
 
 .. note::
 
@@ -235,8 +238,8 @@ It gives developers a quick way to build a new table or change an existing table
     uses under the hood) directly. However, neither of these is extensible.
     You would need to override the panel completely.
 
-This is a sample module file to demonstrate how to make some customizations to the
+This is a sample module file to demonstrate how to make some customizations to
-Images Panel.::
+the Images Panel.::
 
     (function() {
       'use strict';
@@ -287,9 +290,9 @@ Images Panel.::
       }
     })();
 
-Additionally, you should have content defined in ``detail.html`` and ``drawer.html``,
+Additionally, you should have content defined in ``detail.html`` and
-as well as define the ``surpriseService`` which is based off the ``actions``
+``drawer.html``, as well as define the ``surpriseService`` which is based off
-directive and needs allowed and perform methods defined.
+the ``actions`` directive and needs allowed and perform methods defined.
 
 
 Icons
@@ -314,8 +317,8 @@ Custom Stylesheets
 ==================
 
 It is possible to define custom stylesheets for your dashboards. Horizon's base
-template ``openstack_dashboard/templates/base.html`` defines multiple blocks that
+template ``openstack_dashboard/templates/base.html`` defines multiple blocks
-can be overridden.
+that can be overridden.
 
 To define custom css files that apply only to a specific dashboard, create
 a base template in your dashboard's templates folder, which extends Horizon's
@@ -399,7 +402,7 @@ Customizing Meta Attributes
 ===========================
 
 To add custom metadata attributes to your project's base template, include
-them in the ``horizon/_custom_meta.html`` file. The contents of this file will be
+them in the ``horizon/_custom_meta.html`` file. The contents of this file will
-inserted into the page's <head> just after the default Horizon meta tags.
+be inserted into the page's <head> just after the default Horizon meta tags.
 
 ..  _Font Awesome: https://fortawesome.github.io/Font-Awesome/

doc/source/configuration/pluggable_panels.rst

@@ -56,17 +56,19 @@ are added as dependencies on the root Horizon application ``horizon``.
 
 .. versionadded:: 2014.2(Juno)
 
-A list of javascript source files to be included in the compressed set of files that are
+A list of javascript source files to be included in the compressed set of files
-loaded on every page. This is needed for AngularJS modules that are referenced in
+that are loaded on every page. This is needed for AngularJS modules that are
-``ADD_ANGULAR_MODULES`` and therefore need to be included in every page.
+referenced in ``ADD_ANGULAR_MODULES`` and therefore need to be included in
+every page.
 
 ``ADD_JS_SPEC_FILES``
 ---------------------
 
 .. versionadded:: 2015.1(Kilo)
 
-A list of javascript spec files to include for integration with the Jasmine spec runner.
+A list of javascript spec files to include for integration with the Jasmine
-Jasmine is a behavior-driven development framework for testing JavaScript code.
+spec runner. Jasmine is a behavior-driven development framework for testing
+JavaScript code.
 
 ``ADD_SCSS_FILES``
 ------------------
@@ -84,17 +86,19 @@ you need to include additional scss files for panels.
 
 .. versionadded:: 8.0.0(Liberty)
 
-If set to ``True``, JavaScript files and static angular html template files will be
+If set to ``True``, JavaScript files and static angular html template files
-automatically discovered from the `static` folder in each apps listed in ADD_INSTALLED_APPS.
+will be automatically discovered from the `static` folder in each apps listed
+in ADD_INSTALLED_APPS.
 
-JavaScript source files will be ordered based on naming convention: files with extension
+JavaScript source files will be ordered based on naming convention: files with
-`.module.js` listed first, followed by other JavaScript source files.
+extension `.module.js` listed first, followed by other JavaScript source files.
 
-JavaScript files for testing will also be ordered based on naming convention: files with extension
+JavaScript files for testing will also be ordered based on naming convention:
-`.mock.js` listed first, followed by files with extension `.spec.js`.
+files with extension `.mock.js` listed first, followed by files with extension
+`.spec.js`.
 
-If ADD_JS_FILES and/or ADD_JS_SPEC_FILES are also specified, files manually listed there will be
+If ADD_JS_FILES and/or ADD_JS_SPEC_FILES are also specified, files manually
-appended to the auto-discovered files.
+listed there will be appended to the auto-discovered files.
 
 ``DISABLED``
 ------------
@@ -233,8 +237,8 @@ the following content::
     PANEL_GROUP = 'admin'
     REMOVE_PANEL = True
 
-To change the default panel of Admin dashboard to Instances panel, create a file
+To change the default panel of Admin dashboard to Instances panel, create a
-``openstack_dashboard/local/enabled/_80_admin_default_panel.py`` with the
+file ``openstack_dashboard/local/enabled/_80_admin_default_panel.py`` with the
 following content::
 
     PANEL = 'instances'

doc/source/configuration/settings.rst

@@ -244,9 +244,9 @@ Default:
         'admin.volumes': False
     }
 
-If the dict key-value is True, when the view loads, an empty table will be rendered
+If the dict key-value is True, when the view loads, an empty table will be
-and the user will be asked to provide a search criteria first (in case no search
+rendered and the user will be asked to provide a search criteria first (in case
-criteria was provided) before loading any data.
+no search criteria was provided) before loading any data.
 
 Examples:
 
@@ -411,9 +411,10 @@ js_files
 
 Default: ``[]``
 
-A list of javascript source files to be included in the compressed set of files that are
+A list of javascript source files to be included in the compressed set of files
-loaded on every page. This is needed for AngularJS modules that are referenced in
+that are loaded on every page. This is needed for AngularJS modules that are
-``angular_modules`` and therefore need to be include in every page.
+referenced in ``angular_modules`` and therefore need to be include in every
+page.
 
 js_spec_files
 ~~~~~~~~~~~~~
@@ -422,8 +423,9 @@ js_spec_files
 
 Default: ``[]``
 
-A list of javascript spec files to include for integration with the Jasmine spec runner.
+A list of javascript spec files to include for integration with the Jasmine
-Jasmine is a behavior-driven development framework for testing JavaScript code.
+spec runner. Jasmine is a behavior-driven development framework for testing
+JavaScript code.
 
 modal_backdrop
 ~~~~~~~~~~~~~~
@@ -633,12 +635,13 @@ developer feature, it starts as disabled. To enable it, more than a single
 in that dictionary are:
 
 * ``"keys"`` is a list of strings, which are secret keys used to encode/decode
-  the profiler data contained in request headers. Encryption is used for security
+  the profiler data contained in request headers. Encryption is used for
-  purposes, other OpenStack components that are expected to profile themselves
+  security purposes, other OpenStack components that are expected to profile
-  with osprofiler using the data from the request that Horizon initiated must
+  themselves with osprofiler using the data from the request that Horizon
-  share a common set of keys with the ones in Horizon config. List of keys is
+  initiated must share a common set of keys with the ones in Horizon
-  used so that security keys could be changed in non-obtrusive manner for every
+  config. List of keys is used so that security keys could be changed in
-  component in the cloud. Example: ``"keys": ["SECRET_KEY", "MORE_SECRET_KEY"]``.
+  non-obtrusive manner for every component in the cloud.
+  Example: ``"keys": ["SECRET_KEY", "MORE_SECRET_KEY"]``.
   For more details see `osprofiler documentation`_.
 * ``"notifier_connection_string"`` is a url to which trace messages are sent by
   Horizon. For other components it is usually the only URL specified in config,
@@ -940,14 +943,15 @@ web-server. It is equivalent to setting ``True`` on the deprecated setting
 ``HORIZON_IMAGES_ALLOW_UPLOAD``. ``direct`` sends the image file directly from
 the web browser to Glance. This bypasses Horizon web-server which both reduces
 network hops and prevents filling up Horizon web-server's filesystem. ``direct``
-is the preferred mode, but due to the following requirements it is not the default.
+is the preferred mode, but due to the following requirements it is not the
-The ``direct`` setting requires a modern web browser, network access from the
+default. The ``direct`` setting requires a modern web browser, network access
-browser to the public Glance endpoint, and CORS support to be enabled on the
+from the browser to the public Glance endpoint, and CORS support to be enabled
-Glance API service. Without CORS support, the browser will forbid the PUT request
+on the Glance API service. Without CORS support, the browser will forbid the
-to a location different than the Horizon server. To enable CORS support for Glance
+PUT request to a location different than the Horizon server. To enable CORS
-API service, you will need to edit [cors] section of glance-api.conf file (see
+support for Glance API service, you will need to edit [cors] section of
-`here`_ how to do it). Set `allowed_origin` to the full hostname of Horizon
+glance-api.conf file (see `here`_ how to do it). Set `allowed_origin` to the
-web-server (e.g. http://<HOST_IP>/dashboard) and restart glance-api process.
+full hostname of Horizon web-server (e.g. http://<HOST_IP>/dashboard) and
+restart glance-api process.
 
 .. _here: http://docs.openstack.org/developer/oslo.middleware/cors.html#configuration-for-oslo-config
 
@@ -1025,7 +1029,13 @@ id, and optionally a `text` attribute specifying the category name, and
 an `icon` attribute that displays an icon in the filter button. The
 icon names are based on the default icon theme provided by Bootstrap.
 
-Example: ``[{'text': 'Official', 'tenant': '27d0058849da47c896d205e2fc25a5e8', 'icon': 'fa-check'}]``
+Example:
+
+.. code-block:: python
+
+   [{'text': 'Official',
+     'tenant': '27d0058849da47c896d205e2fc25a5e8',
+     'icon': 'fa-check'}]
 
 OPENSTACK_IMAGE_BACKEND
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -1086,7 +1096,7 @@ AUTHENTICATION_PLUGINS
 
 .. versionadded:: 2015.1(Kilo)
 
-Default: 
+Default:
 
 .. code-block:: python
 
@@ -1267,9 +1277,9 @@ OPENSTACK_KEYSTONE_FEDERATION_MANAGEMENT
 Default: ``False``
 
 Set this to True to enable panels that provide the ability for users to manage
-Identity Providers (IdPs) and establish a set of rules to map federation protocol
+Identity Providers (IdPs) and establish a set of rules to map federation
-attributes to Identity API attributes. This extension requires v3.0+ of the
+protocol attributes to Identity API attributes. This extension requires v3.0+
-Identity API.
+of the Identity API.
 
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

doc/source/configuration/themes.rst

@@ -14,7 +14,8 @@ toggle between the configured themes.  By default, Horizon is configured
 with the two standard themes available: 'default' and 'material'.
 
 To configure or alter the available themes, set ``AVAILABLE_THEMES`` in
-``local_settings.py`` to a list of tuples, such that ``('name', 'label', 'path')``
+``local_settings.py`` to a list of tuples, such that
+``('name', 'label', 'path')``
 
 ``name``
   The key by which the theme value is stored within the cookie
@@ -46,8 +47,9 @@ A configuration with a single theme::
   ]
 
 Both the Dashboard custom variables and Bootstrap variables can be overridden.
-For a full list of the Dashboard SCSS variables that can be changed, see the
+For a full list of the Dashboard SCSS variables that can be changed,
-variables file at ``openstack_dashboard/static/dashboard/scss/_variables.scss``.
+see the variables file at
+``openstack_dashboard/static/dashboard/scss/_variables.scss``.
 
 In order to build a custom theme, both ``_variables.scss`` and ``_styles.scss``
 are required and ``_variables.scss`` must provide all the default Bootstrap
@@ -86,8 +88,8 @@ Horizon packages the Bootswatch SCSS files for use with its ``material`` theme.
 Because of this, it is simple to use an existing Bootswatch theme as a base.
 This is due to the fact that Bootswatch is loaded as a 3rd party static asset,
 and therefore is automatically collected into the `static` directory in
-`/horizon/lib/`.  The following is an example of how to inherit from Bootswatch's
+`/horizon/lib/`.  The following is an example of how to inherit from
-``darkly`` theme::
+Bootswatch's ``darkly`` theme::
 
   @import "/horizon/lib/bootswatch/darkly/variables";
   @import "/horizon/lib/bootswatch/darkly/bootswatch";
@@ -152,9 +154,9 @@ theme's static root directory and place your custom ``logo.svg`` or
 ``logo-splash.svg`` within it.
 
 If you wish to override the ``logo.svg`` using the previous method, and if the
-image used is larger than the height of the top navigation, then the image will be
+image used is larger than the height of the top navigation, then the image will
-constrained to fit within the height of nav.  You can customize the height of
+be constrained to fit within the height of nav.  You can customize the height
-the top navigation bar by customizing the SCSS variable: ``$navbar-height``.
+of the top navigation bar by customizing the SCSS variable: ``$navbar-height``.
 If the image's height is smaller than the navbar height, then the image
 will retain its original resolution and size, and simply be centered
 vertically in the available space.

doc/source/contributor/contributing.rst

@@ -58,7 +58,8 @@ plunging in head-first:
   mailing list on the project page, or on IRC.
 * Write documentation!
 * Write unit tests for untested code!
-* Help improve the `User Experience Design`_ or contribute to the `Persona Working Group`_.
+* Help improve the `User Experience Design`_ or contribute to the
+  `Persona Working Group`_.
 
 .. _`bug tracker`: https://bugs.launchpad.net/horizon
 .. _`Launchpad Blueprints`: https://blueprints.launchpad.net/horizon
@@ -90,9 +91,11 @@ After You Write Your Patch
 Once you've made your changes, there are a few things to do:
 
 * Make sure the unit tests and linting tasks pass by running ``tox``
-* Take a look at your patch in API profiler, i.e. how it impacts the performance. See `Profiling Pages`_.
+* Take a look at your patch in API profiler, i.e. how it impacts the
+  performance. See `Profiling Pages`_.
 * Make sure your code is ready for translation: See :ref:`pseudo_translation`.
-* Make sure your code is up-to-date with the latest master: ``git pull --rebase``
+* Make sure your code is up-to-date with the latest master:
+  ``git pull --rebase``
 * Finally, run ``git review`` to upload your changes to Gerrit for review.
 
 The Horizon core developers will be notified of the new review and will examine
@@ -114,7 +117,8 @@ be able to use "Profile" menu, the following steps need to be completed:
 #. Enable the Developer dashboard by copying ``_9001_developer.py`` from
    ``openstack_dashboard/contrib/developer/enabled/`` to
    ``openstack_dashboard/local/enabled/``.
-#. Copy ``openstack_dashboard/local/local_settings.d/_9030_profiler_settings.py.example``
+#. Copy
+   ``openstack_dashboard/local/local_settings.d/_9030_profiler_settings.py.example``
    to ``openstack_dashboard/local/local_settings.d/_9030_profiler_settings.py``
 #. Copy ``openstack_dashboard/contrib/developer/enabled/_9030_profiler.py`` to
    ``openstack_dashboard/local/enabled/_9030_profiler.py``.
@@ -449,8 +453,9 @@ To create a new xstatic package:
 
 To make a new release of the package, you need to:
 
-1. Ensure the version information in the `xstatic/pkg/<package name>/__init__.py`
+1. Ensure the version information in the
-   file is up to date, especially the `BUILD`.
+   `xstatic/pkg/<package name>/__init__.py` file is up to date,
+   especially the `BUILD`.
 2. Push your updated package up for review in gerrit.
 3. Once the review is approved and the change merged, `request a release`_ by
    updating or creating the appropriate file for the xstatic package
@@ -481,35 +486,41 @@ Integrating a new xstatic package into Horizon
 
 Having done a release of an xstatic package:
 
-1. Look for the `upper-constraints.txt`_ edit related to the xstatic release that was just
+1. Look for the `upper-constraints.txt`_ edit related to the xstatic release
-   performed. One will be created automatically by the release process in the
+   that was just performed. One will be created automatically by the release
-   ``openstack/requirements`` project with the topic `new-release`_. You should -1 that
+   process in the ``openstack/requirements`` project with the topic
-   patch until you are confident Horizon does not break (or you have generated a patch to
+   `new-release`_. You should -1 that patch until you are confident Horizon
-   fix Horizon for that release.) If no upper-constraints.txt patch is automatically
+   does not break (or you have generated a patch to fix Horizon for that
-   generated, ensure the releases yaml file created in the `releases repository`_ has the
+   release.) If no upper-constraints.txt patch is automatically generated,
+   ensure the releases yaml file created in the `releases repository`_ has the
    "include-pypi-link: yes" setting.
-2. Pull that patch down so you have the edited upper-constraints.txt file locally.
+2. Pull that patch down so you have the edited upper-constraints.txt file
-3. Set the environment variable `UPPER_CONSTRAINTS_FILE` to the edited upper-constraints.txt
+   locally.
-   file name and run tests or local development server through tox. This will pull in the
+3. Set the environment variable `UPPER_CONSTRAINTS_FILE` to the edited
-   precise version of the xstatic package that you need.
+   upper-constraints.txt file name and run tests or local development server
+   through tox. This will pull in the precise version of the xstatic package
+   that you need.
 4. Move on to releasing once you're happy the Horizon changes are stable.
 
-Releasing a new compatible version of Horizon to address issues in the new xstatic release:
+Releasing a new compatible version of Horizon to address issues in the new
+xstatic release:
 
-1. Continue to -1 the upper-constraints.txt patch above until this process is complete. A +1
+1. Continue to -1 the upper-constraints.txt patch above until this process is
-   from a Horizon developer will indicate to the requirements team that the upper-constraints.txt
+   complete. A +1 from a Horizon developer will indicate to the requirements
-   patch is OK to merge.
+   team that the upper-constraints.txt patch is OK to merge.
-2. When submitting your changes to Horizon to address issues around the new xstatic release,
+2. When submitting your changes to Horizon to address issues around the new
-   use a Depends-On: referencing the upper-constraints.txt review. This will cause the OpenStack
+   xstatic release, use a Depends-On: referencing the upper-constraints.txt
-   testing infrastructure to pull in your updated xstatic package as well.
+   review. This will cause the OpenStack testing infrastructure to pull in your
-3. Merge the upper-constraints.txt patch and the Horizon patch noting that Horizon's gate may be
+   updated xstatic package as well.
-   broken in the interim between these steps, so try to minimise any delay there. With the
+3. Merge the upper-constraints.txt patch and the Horizon patch noting that
-   Depends-On it's actually safe to +W the Horizon patch, which will be held up until the
+   Horizon's gate may be broken in the interim between these steps, so try to
-   related upper-constraints.txt patch merges.
+   minimise any delay there. With the Depends-On it's actually safe to +W the
-4. Once the upper-constraints.txt patch merges, you should propose a patch to global-requirements
+   Horizon patch, which will be held up until the related upper-constraints.txt
-   which bumps the minimum version of the package up to the upper-constraints version so that
+   patch merges.
-   deployers / packagers who don't honor upper-constraints still get compatible versions of
+4. Once the upper-constraints.txt patch merges, you should propose a patch to
-   the packages.
+   global-requirements which bumps the minimum version of the package up to the
+   upper-constraints version so that deployers / packagers who don't honor
+   upper-constraints still get compatible versions of the packages.
 
 .. _upper-constraints.txt: https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
 .. _new-release: https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:new-release
@@ -553,13 +564,15 @@ Unexpected warnings often appear when building the documentation, and slight
 reST syntax errors frequently cause links or cross-references not to work
 correctly.
 
-Documentation is generated with Sphinx using the tox command. To create HTML docs and man pages:
+Documentation is generated with Sphinx using the tox command. To create HTML
+docs and man pages:
 
 .. code-block:: bash
 
     $ tox -e docs
 
-The results are in the doc/build/html and doc/build/man directories respectively.
+The results are in the doc/build/html and doc/build/man directories
+respectively.
 
 Conventions
 -----------

doc/source/contributor/quickstart.rst

@@ -265,8 +265,8 @@ an example)
 Dashboard Classes
 -----------------
 
-Inside of ``dashboard.py`` you would have a class definition and the registration
+Inside of ``dashboard.py`` you would have a class definition and the
-process
+registration process
 
 .. code-block:: python
 

doc/source/contributor/ref/tables.rst

@@ -8,9 +8,9 @@ Horizon DataTables
 
 Horizon includes a componentized API for programmatically creating tables
 in the UI. Why would you want this? It means that every table renders
-correctly and consistently, table-level and row-level actions all have a consistent
+correctly and consistently, table-level and row-level actions all have a
-API and appearance, and generally you don't have to reinvent the wheel or
+consistent API and appearance, and generally you don't have to reinvent the
-copy-and-paste every time you need a new table!
+wheel or copy-and-paste every time you need a new table!
 
 .. seealso::
 
@@ -54,7 +54,8 @@ The following options can be defined in a ``Meta`` class inside a
 FormsetDataTable
 ================
 
-You can integrate the :class:`.DataTable` with a Django Formset using one of following classes:
+You can integrate the :class:`.DataTable` with a Django Formset using one of
+following classes:
 
 .. autoclass:: horizon.tables.formset.FormsetDataTableMixin
     :members:

doc/source/contributor/testing.rst

@@ -85,10 +85,12 @@ tox::
   $ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests
 
 The following is more example to run a specific test class and a
-specific test::
+specific test:
 
-  $ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests
+.. code-block:: console
-  $ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests.test_index
+
+   $ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests
+   $ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests.test_index
 
 You can also pass other arguments. For example, to drop into a live debugger
 when a test fails you can use::
@@ -117,6 +119,11 @@ Also takes an alternative builder as an optional argument, such as
 ``releasenotes/build/<builder>``. Available builders are listed at
 http://www.sphinx-doc.org/en/latest/builders.html
 
+This environment also runs the documentation style checker ``doc8`` against
+RST and YAML files under ``releasenotes/source`` to keep the documentation
+style consistent. If you would like to run ``doc8`` manually, see **docs**
+environment below.
+
 npm
 ---
 
@@ -142,6 +149,16 @@ Example::
 
   $ tox -e docs -- latexpdf
 
+This environment also runs the documentation style checker ``doc8`` against
+RST files under ``doc/source`` to keep the documentation style consistent.
+If you would like to run ``doc8`` manually, run:
+
+.. code-block:: console
+
+   # Activate virtualenv
+   $ . .tox/docs/bin/activate
+   $ doc8 doc/source
+
 Writing tests
 =============
 

doc/source/contributor/topics/angularjs.rst

@@ -40,8 +40,8 @@ ESLint
 
 ESLint is a tool for identifying and reporting on patterns in your JS code, and
 is part of the automated tests run by Jenkins. You can run ESLint from the
-horizon root directory with ``tox -e npm -- lint``, or alternatively on a specific
+horizon root directory with ``tox -e npm -- lint``, or alternatively on a
-directory or file with ``eslint file.js``.
+specific directory or file with ``eslint file.js``.
 
 Horizon includes a `.eslintrc` in its root directory, that is used by the
 local tests. An explanation of the options, and details of others you may want
@@ -73,8 +73,8 @@ Horizon has three kinds of angular code:
    dashboards
 3. Reusable by any application based on the Horizon framework
 
-When adding code to horizon, consider whether it is dashboard-specific or should be
+When adding code to horizon, consider whether it is dashboard-specific or
-broken out as a reusable utility or widget.
+should be broken out as a reusable utility or widget.
 
 Code specific to one dashboard
 ------------------------------
@@ -148,8 +148,8 @@ The top-level SCSS file in ``openstack_dashboard/static/app/_app.scss``. It
 includes any styling that is part of the application ``core`` and may be
 reused by multiple dashboards. SCSS files that are specific to a particular
 dashboard are linked to the application by adding them in that dashboard's
-enabled file. For example, `_1920_project_containers_panel.py` is the enabled file
+enabled file. For example, `_1920_project_containers_panel.py` is the enabled
-for the ``Project`` dashboard's ``Container`` panel and includes:
+file for the ``Project`` dashboard's ``Container`` panel and includes:
 ::
 
     ADD_SCSS_FILES = [
@@ -157,8 +157,8 @@ for the ``Project`` dashboard's ``Container`` panel and includes:
     ]
 
 Styling files are hierarchical, and include any direct child SCSS files. For
-example, ``project.scss`` would includes the ``workflow`` SCSS file, which in turn
+example, ``project.scss`` would includes the ``workflow`` SCSS file, which in
-includes any launch instance styling:
+turn includes any launch instance styling:
 ::
 
     @import "workflow/workflow";
@@ -169,9 +169,9 @@ including a dashboard's top-level SCSS file.
 Module Structure
 ================
 
-Horizon Angular modules use names that map to the source code directory structure.
+Horizon Angular modules use names that map to the source code directory
-This provides namespace isolation for modules and services, which makes
+structure. This provides namespace isolation for modules and services, which
-dependency injection clearer. It also reduces code conflicts where two
+makes dependency injection clearer. It also reduces code conflicts where two
 different modules define a module, service or constant of the same name. For
 example:
 ::
@@ -218,9 +218,9 @@ application to access any widget, simply by depending on the top-level
 Testing
 =======
 
-1. Open <dev_server_ip:port>/jasmine in a browser. The development server can be run
+1. Open <dev_server_ip:port>/jasmine in a browser. The development server can
-   with ``tox -e runserver`` from the horizon root directory; by default, this will
+   be run with ``tox -e runserver`` from the horizon root directory; by
-   run the development server at ``http://localhost:8000``.
+   default, this will run the development server at ``http://localhost:8000``.
 2. ``tox -e npm`` from the horizon root directory.
 
 The code linting job can be run with ``tox -e npm -- lint``. If there are many
@@ -251,8 +251,8 @@ Creating your own panel
   ``ADD_ANGULAR_MODULES``, even when using automatic file discovery.
 
 This section serves as a basic introduction to writing your own panel for
-horizon, using AngularJS. A panel may be included with the plugin system, or it may be
+horizon, using AngularJS. A panel may be included with the plugin system, or it
-part of the upstream horizon project.
+may be part of the upstream horizon project.
 
 Upstream
 --------
@@ -266,16 +266,20 @@ To use the automatic functionality, add::
 to your enabled file (``enabled/<plugin_name>.py``). To make this possible,
 you need to follow some structural conventions:
 
-- Static files should be put in a ``static/`` folder, which should be found directly under
+- Static files should be put in a ``static/`` folder, which should be found
-  the folder for the dashboard/panel/panel groups Python package.
+  directly under the folder for the dashboard/panel/panel groups Python
-- JS code that defines an Angular module should be in a file with extension of ``.module.js``.
+  package.
-- JS code for testing should be named with extension of ``.mock.js`` and of ``.spec.js``.
+- JS code that defines an Angular module should be in a file with extension of
+  ``.module.js``.
+- JS code for testing should be named with extension of ``.mock.js`` and of
+  ``.spec.js``.
 - Angular templates should have extension of ``.html``.
 
 You can read more about the functionality in the
 :ref:`auto_discover_static_files` section of the settings documentation.
 
-To manually add files, add the following arrays and file paths to the enabled file:
+To manually add files, add the following arrays and file paths to the enabled
+file:
 ::
 
   ADD_JS_FILES = [
@@ -299,8 +303,8 @@ To manually add files, add the following arrays and file paths to the enabled fi
 Plugins
 -------
 
-Add a new panel/ panel group/ dashboard (See :ref:`tutorials-dashboard`). JavaScript file
+Add a new panel/ panel group/ dashboard (See :ref:`tutorials-dashboard`).
-inclusion is the same as the Upstream process.
+JavaScript file inclusion is the same as the Upstream process.
 
 To include external stylesheets, you must ensure that ``ADD_SCSS_FILES`` is
 defined in your enabled file, and add the relevant filepath, as below:
@@ -323,10 +327,10 @@ defined in your enabled file, and add the relevant filepath, as below:
 Schema Forms
 ============
 
-`JSON schemas`_ are used to define model layout and then `angular-schema-form`_ is
+`JSON schemas`_ are used to define model layout and then `angular-schema-form`_
-used to create forms from that schema. Horizon adds some functionality on top of
+is used to create forms from that schema. Horizon adds some functionality on
-that to make things even easier through ``ModalFormService`` which will open a
+top of that to make things even easier through ``ModalFormService`` which will
-modal with the form inside.
+open a modal with the form inside.
 
 A very simple example::
 

doc/source/contributor/topics/javascript_testing.rst

@@ -20,8 +20,8 @@ There are multiple components in our JavaScript testing framework:
   See :ref:`js_code_style` for more detail.
 
 Jasmine uses specs (``.spec.js``) which are kept with the JavaScript files
-that they are testing. See the :ref:`js_file_structure` section or the `Examples`_
+that they are testing. See the :ref:`js_file_structure` section or the
-below for more detail on this.
+`Examples`_ below for more detail on this.
 
 .. _Jasmine: https://jasmine.github.io/2.3/introduction.html
 .. _Karma: https://karma-runner.github.io/
@@ -43,14 +43,14 @@ The code linting job can be run with ``tox -e npm -- lint``, or
 ``tox -e npm -- lintq`` to show errors, but not warnings.
 
 To decipher where tests are failing it may be useful to use Jasmine in the
-browser to run individual tests to see where the tests are specifically breaking.
+browser to run individual tests to see where the tests are specifically
-To do this, navigate to your local horizon in the browser and add
+breaking. To do this, navigate to your local horizon in the browser and add
-'/jasmine' to the end of the url. e.g: 'http://localhost:8000/jasmine'. Once you
+'/jasmine' to the end of the url. e.g: 'http://localhost:8000/jasmine'. Once
-have the jasmine report you may click on the title of an individual test to
+you have the jasmine report you may click on the title of an individual test to
 re-run just that test. From here, you can also use chrome dev tools or similar
 to set breakpoints in the code by accessing the 'Sources' tab and clicking on
-lines of code where you wish to break the code. This will then show you the exact
+lines of code where you wish to break the code. This will then show you the
-places where the code breaks.
+exact places where the code breaks.
 
 Coverage Reports
 ----------------
@@ -61,7 +61,8 @@ compare your development branch; this will help identify missing tests.
 
 To generate coverage reports, run ``tox -e npm``. The coverage reports can be
 found at ``cover/horizon/`` (framework tests) and ``cover/openstack_dashboard/``
-(dashboard tests). Load ``<browser>/index.html`` in a browser to view the reports.
+(dashboard tests). Load ``<browser>/index.html`` in a browser to view the
+reports.
 
 Writing Tests
 =============

doc/source/contributor/topics/packaging.rst

@@ -152,7 +152,7 @@ maintainers. Some of the most important ones are:
 - Configuration must always be in /etc, no matter what. When this rule
   was not followed, package maintainers had to place symlinks to
   ``/etc/openstack-dashboard/local_settings`` in Red Hat based distributions
-  instead of using directly 
+  instead of using directly
   ``/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py``
   which Horizon expects. In Debian,the configuration file is named
   ``/etc/openstack-dashboard/local_settings.py.``

doc/source/contributor/topics/policy.rst

@@ -148,8 +148,9 @@ An Example looks like::
       policy.ifAllowed({ rules: rules }).then(policySuccess, policyFailed);
     }
 
-The fourth way to add a role based check is in html files. Use angular directive 'hz-if-policies'
+The fourth way to add a role based check is in html files. Use angular
-in file 'openstack_dashboard/static/app/core/cloud-services/hz-if-policies.directive.js'.
+directive 'hz-if-policies' in file
+'openstack_dashboard/static/app/core/cloud-services/hz-if-policies.directive.js'.
 Assume you have the following policy defined in your angular controller::
 
     ctrl.policy = { rules: [["identity", "identity:update_user"]] }

doc/source/contributor/topics/testing.rst

@@ -234,17 +234,17 @@ Coverage reports
 
 It is possible for tests to fail on your patch due to the npm-run-test not
 passing the minimum threshold. This is not necessarily related directly to the
-functions in the patch that have failed, but more that there are not enough tests
+functions in the patch that have failed, but more that there are not enough
-across horizon that are related to your patch.
+tests across horizon that are related to your patch.
 
-The coverage reports may be found in the 'cover' directory. There's a subdirectory
+The coverage reports may be found in the 'cover' directory. There's a
-for horizon and openstack_dashboard, and then under a directory for the browser
+subdirectory for horizon and openstack_dashboard, and then under a directory
-used to run the tests you should find an ``index.html``. This can then be viewed
+for the browser used to run the tests you should find an ``index.html``. This
-to see the coverage details.
+can then be viewed to see the coverage details.
 
-In this scenario you may need to submit a secondary patch to address test coverage
+In this scenario you may need to submit a secondary patch to address test
-for another function within horizon to ensure tests rise above the coverage
+coverage for another function within horizon to ensure tests rise above the
-threshold and your original patch can pass the necessary tests.
+coverage threshold and your original patch can pass the necessary tests.
 
 Common pitfalls
 ---------------

doc/source/contributor/tutorials/dashboard.rst

@@ -149,11 +149,11 @@ As described above, the ``mypanel`` directory under
 Defining a panel
 ----------------
 
-The ``panel.py`` file referenced above has a special meaning. Within a dashboard,
+The ``panel.py`` file referenced above has a special meaning.
-any module name listed in the ``panels`` attribute on the dashboard class will
+Within a dashboard, any module name listed in the ``panels`` attribute on the
-be auto-discovered by looking for the ``panel.py`` file in a corresponding
+dashboard class will be auto-discovered by looking for the ``panel.py`` file in
-directory (the details are a bit magical, but have been thoroughly vetted in
+a corresponding directory (the details are a bit magical, but have been
-Django's admin codebase).
+thoroughly vetted in Django's admin codebase).
 
 Open the ``panel.py`` file, you will have the following auto-generated code::
 
@@ -233,12 +233,11 @@ view from the pieces.
 Defining a table
 ~~~~~~~~~~~~~~~~
 
-Horizon provides a :class:`~horizon.forms.SelfHandlingForm`  :class:`~horizon.tables.DataTable` class which simplifies
+Horizon provides a :class:`~horizon.forms.SelfHandlingForm`
-the vast majority of displaying data to an end-user. We're just going to skim
+:class:`~horizon.tables.DataTable` class which simplifies the vast majority of
-the surface here, but it has a tremendous number of capabilities.
+displaying data to an end-user. We're just going to skim the surface here, but
-
+it has a tremendous number of capabilities. Create a ``tables.py`` file under
-Create a ``tables.py`` file under the ``mypanel`` directory and add the
+the ``mypanel`` directory and add the following code::
-following code::
 
     from django.utils.translation import ugettext_lazy as _
 
@@ -283,7 +282,8 @@ on a table's data:
 - :class:`~horizon.tables.FilterAction`
 
 
-There are also additional actions which are extensions of the basic Action classes:
+There are also additional actions which are extensions of the basic Action
+classes:
 
 - :class:`~horizon.tables.BatchAction`
 - :class:`~horizon.tables.DeleteAction`
@@ -440,8 +440,8 @@ no work on the user's end. Change ``views.APIView`` to be
         tab_group_class = mydashboard_tabs.MypanelTabs
 
 
-After importing the proper package, the completed ``views.py`` file  now looks like
+After importing the proper package, the completed ``views.py`` file  now looks
-the following::
+like the following::
 
     from horizon import tabs
 
@@ -570,7 +570,7 @@ Click it, ``My Group`` will expand with ``My Panel``. Click on ``My Panel``,
 the right side panel will display an ``Instances Tab`` which has an
 ``Instances`` table.
 
-If you don't see any instance data, you haven't created any instances yet.  Go to
+If you don't see any instance data, you haven't created any instances yet. Go to
 dashboard ``Project`` -> ``Images``, select a small image, for example,
 ``cirros-0.3.1-x86_64-uec`` , click ``Launch`` and enter an ``Instance Name``,
 click the button ``Launch``. It should create an instance if the OpenStack or

doc/source/contributor/tutorials/plugin.rst

@@ -441,7 +441,8 @@ in ``ADD_INSTALLED_APPS`` in the corresponding ``enabled`` file.
   as ``INSTALLED_APPS`` in most cases as suggested in this tutorial.
   This is good and there is nothing more to do.
 * If for some reason your plugin needs to register other python modules
-  to ``ADD_INSTALLED_APPS``, ensure that you include its ``<modulename>`` additionally.
+  to ``ADD_INSTALLED_APPS``, ensure that you include its ``<modulename>``
+  additionally.
 
 This comes from the combination of the following two reasons.
 

doc/source/contributor/tutorials/table_actions.rst

@@ -4,8 +4,9 @@
 Tutorial: Adding a complex action to a table
 ============================================
 
-This tutorial covers how to add a more complex action to a table, one that requires
+This tutorial covers how to add a more complex action to a table, one that
-an action and form definitions, as well as changes to the view, urls, and table.
+requires an action and form definitions, as well as changes to the view, urls,
+and table.
 
 This tutorial assumes you have already completed
 :ref:`tutorials-dashboard`. If not, please do so now as we will be
@@ -13,14 +14,14 @@ modifying the files created there.
 
 This action will create a snapshot of the instance. When the action is taken,
 it will display a form that will allow the user to enter a snapshot name,
-and will create that snapshot when the form is closed using the ``Create snapshot``
+and will create that snapshot when the form is closed using the ``Create
-button.
+snapshot`` button.
 
 Defining the view
 =================
 
-To define the view, we must create a view class, along with the template (``HTML``)
+To define the view, we must create a view class, along with the template
-file and the form class for that view.
+(``HTML``) file and the form class for that view.
 
 The template file
 -----------------
@@ -58,13 +59,14 @@ directory. It should contain the following code::
 The form
 --------
 
-Horizon provides a :class:`~horizon.forms.base.SelfHandlingForm` class which simplifies
+Horizon provides a :class:`~horizon.forms.base.SelfHandlingForm` class which
-some of the details involved in creating a form. Our form will derive from this
+simplifies some of the details involved in creating a form. Our form will
-class, adding a character field to allow the user to specify a name for the
+derive from this class, adding a character field to allow the user to specify
-snapshot, and handling the successful closure of the form by calling the nova
+a name for the snapshot, and handling the successful closure of the form by
-api to create the snapshot.
+calling the nova api to create the snapshot.
 
-Create the ``forms.py`` file under the ``mypanel`` directory and add the following::
+Create the ``forms.py`` file under the ``mypanel`` directory and add the
+following::
 
     from django.core.urlresolvers import reverse
     from django.utils.translation import ugettext_lazy as _
@@ -96,8 +98,8 @@ The view
 --------
 
 Now, the view will tie together the template and the form. Horizon provides a
-:class:`~horizon.forms.views.ModalFormView` class which simplifies the creation of a
+:class:`~horizon.forms.views.ModalFormView` class which simplifies the creation
-view that will contain a modal form.
+of a view that will contain a modal form.
 
 Open the ``views.py`` file under the ``mypanel`` directory and add the code
 for the CreateSnapshotView and the necessary imports. The complete

releasenotes/notes/admin-neutron-l3-agents-dd6274467572906b.yaml

@@ -2,7 +2,8 @@
 features:
   - >
    [`blueprint admin-neutron-l3-agent <https://blueprints.launchpad.net/horizon/+spec/admin-neutron-l3-agent>`_]
-   Add support for managing neutron L3 agent hosts.  The admin screen for system information now provides
+   Add support for managing neutron L3 agent hosts. The admin screen for system
-   links / views to see what routers reside on what hosts.   In addition, the admin view of routers
+   information now provides links / views to see what routers reside on what
-   now also provides a list of where the router is hosted and the link to see what other routers are sharing
+   hosts. In addition, the admin view of routers now also provides a list of
-   the same host.
+   where the router is hosted and the link to see what other routers are
+   sharing the same host.

releasenotes/notes/bp-add-server-metadata-a5d5582966ef25c5.yaml

@@ -2,4 +2,4 @@
 features:
   - Added the Metadata tab to the new Launch Instance workflow to allow adding
     key-value metadata to an instance at launch. This includes any properties
-    from the OS::Nova::Server namespace of the glance metadata definitions.
+    from the OS::Nova::Server namespace of the glance metadata definitions.

releasenotes/notes/bp-admin-views-filter-first-5b0d8a02b1271135.yaml

@@ -4,4 +4,4 @@ features:
     [`blueprint admin-views-filter-first <https://blueprints.launchpad.net/horizon/+spec/admin-views-filter-first>`_]
     This blueprint provides a configurable setting to allow operators
     require admin users to provide a search criteria first before loading data
-    into admin views.
+    into admin views.

releasenotes/notes/bp-angular-template-overrides-9f05ffd61367245a.yaml

@@ -8,4 +8,4 @@ features:
     openstack_dashboard/themes/material/static/templates/framework
     /widgets/help-panel/help-panel.html. All of the client side templates are
     now compiled into a single JavaScript file that is minified and is given
-    as an additional file in the manifest.json file.
+    as an additional file in the manifest.json file.

releasenotes/notes/bp-cinder-consistency-groups-7cc98fda0ff3bb7a.yaml

@@ -2,12 +2,11 @@
 features:
   - >
     [`blueprint cinder-consistency-groups <https://blueprints.launchpad.net/horizon/+spec/cinder-consistency-groups>`_]
-    This feature adds 2 new tabs to the Project Volumes panel. The first tab will display
+    This feature adds 2 new tabs to the Project Volumes panel. The first tab
-    Consistency Groups, and the second tab will display Consistency Group Snapshots.
+    will display Consistency Groups, and the second tab will display
-    Consistency Groups (CG) contain existing volumes, and allow the user to perform
+    Consistency Group Snapshots. Consistency Groups (CG) contain existing
-    actions on the volumes in one step. Actions include: create/update/delete CGs,
+    volumes, and allow the user to perform actions on the volumes in one step.
-    snapshot all volumes in a CG, clone all volumes in a CG, and create a new CG and
+    Actions include: create/update/delete CGs, snapshot all volumes in a CG,
-    volumes from a CG snapshot.
+    clone all volumes in a CG, and create a new CG and volumes from a CG
-
+    snapshot. Policies associated with Consistency Groups exist in the Cinder
-    Policies associated with Consistency Groups exist in the Cinder policy file, and
+    policy file, and by default, all actions are disabled.
-    by default, all actions are disabled.

releasenotes/notes/bp-cinder-consistency-groups-b0aba555b1ed4a6c.yaml

@@ -3,10 +3,10 @@ features:
   - >
     [`blueprint cinder-consistency-groups <https://blueprints.launchpad.net/horizon/+spec/cinder-consistency-groups>`_]
     This feature adds a new Consistency Groups tab to the Project Volumes panel.
-    Consistency Groups (GG) contain existing volumes, and allow the user to perform
+    Consistency Groups (GG) contain existing volumes, and allow the user to
-    actions on the volumes in one step. Actions include: create a CG, manage volumes
+    perform actions on the volumes in one step. Actions include: create a CG,
-    associated with the CG, update a CG, and delete a CGs. Note that a CG can not be
+    manage volumes associated with the CG, update a CG, and delete a CGs. Note
-    deleted if it contains any volumes.
+    that a CG can not be deleted if it contains any volumes.
 security:
-  - Policies associated with Consistency Groups exist in the Cinder policy file, and
+  - Policies associated with Consistency Groups exist in the Cinder policy
-    by default, all actions are disabled.
+    file, and by default, all actions are disabled.

releasenotes/notes/bp-configurable-boot-sources-4ba89f3b2a927801.yaml

@@ -2,7 +2,7 @@
 features:
   - >
    [`blueprint configurable-boot-sources <https://blueprints.launchpad.net/horizon/+spec/configurable-boot-sources>`_]
-   Allows administrators to restrict which sources are available to boot from in the
+   Allows administrators to restrict which sources are available to boot from
-   Launch Instance modal by adding 4 new settings to
+   in the Launch Instance modal by adding 4 new settings to
-   LAUNCH_INSTANCE_DEFAULTS (disable_image, disable_instance_snapshot, disable_volume,
+   LAUNCH_INSTANCE_DEFAULTS (disable_image, disable_instance_snapshot,
-   disable_volume_snapshot).
+   disable_volume, disable_volume_snapshot).

releasenotes/notes/bp-edit-server-metadata-7e6b00946a2e793a.yaml

@@ -1,2 +1,3 @@
 features:
-  - Instance metadata can be updated (https://blueprints.launchpad.net/horizon/+spec/edit-server-metadata)
+  - Instance metadata can be updated
+    (https://blueprints.launchpad.net/horizon/+spec/edit-server-metadata)

releasenotes/notes/bp-horizon-vendor-split-4451bc1988485957.yaml

@@ -1,6 +1,6 @@
 ---
 deprecations:
     - Router rules is a horizon extension provided by Big Switch Networks.
-      As part of the horizon-vendor-split work, we drop the extension from upstream horizon.
+      As part of the horizon-vendor-split work, we drop the extension from
-      It is now available as a separate plugin at https://github.com/bigswitch/horizon-bsn
+      upstream horizon. It is now available as a separate plugin at
-
+      https://github.com/bigswitch/horizon-bsn

releasenotes/notes/bp-password-expires-validation-28b7ea155404b778.yaml

@@ -5,4 +5,4 @@ features:
     This blueprint provides a configurable setting to allow operators
     set the threshold days between the current date and the expiration date
     to show a message to warn users change their password prior the expiration
-    date.
+    date.

releasenotes/notes/bp-port-allowed-address-pairs-extension-a05c3a864f494b0c.yaml

@@ -3,4 +3,4 @@ features:
   - The port-details page has a new tab for managing Allowed Address Pairs.
     This tab and its features will only be available when this extension is
     active in Neutron. The Allowed Address Pairs tab will enable creating,
-    deleting, and listing address pairs for the current port.
+    deleting, and listing address pairs for the current port.

releasenotes/notes/drop-settings-enable-fireall-vpn-fad7c1a4cd96df2b.yaml

@@ -7,6 +7,6 @@ upgrade:
     use ``REMOVE_PANEL`` of `the Pluggable Panel mechanism
     <https://docs.openstack.org/developer/horizon/topics/settings.html#pluggable-settings-for-panels>`
     to disable these panels. Note that Horizon checks the availability of
-    FWaaS v1 and/or VPNaaS in your Neutron deploymennt and disables corresponding
+    FWaaS v1 and/or VPNaaS in your Neutron deploymennt and disables
-    panels if not available, so in most cases you do not need to take care of
+    corresponding panels if not available, so in most cases you do not need to
-    the change.
+    take care of the change.

releasenotes/notes/dynamic-themes-b6b02238e47b99f8.yaml

@@ -9,4 +9,4 @@ features:
     available, 'default' and 'material'.
 deprecations:
   - The setting CUSTOM_THEME_PATH is now deprecated.
-  - The setting DEFAULT_THEME_PATH is now deprecated.
+  - The setting DEFAULT_THEME_PATH is now deprecated.

releasenotes/notes/extensible-service-a8689c89a71f8961.yaml

@@ -4,4 +4,4 @@ features:
     such as workflows, tables, actions, and forms to be extended dynamically by
     adding, removing, or replacing items. The extensible service is applied to
     every workflow created using the horizon workflow service. This includes the
-    angular Launch Instance workflow.
+    angular Launch Instance workflow.

releasenotes/notes/gb-to-gib-conversion-8a91839030a2f570.yaml

@@ -1,12 +1,12 @@
 ---
 prelude: >
-    Cinder defines storage size in gibibytes (GiB), which is inconsistent with Horizon panels that
+    Cinder defines storage size in gibibytes (GiB), which is inconsistent with
-    show/request storage size in gigabytes (GB).
+    Horizon panels that show/request storage size in gigabytes (GB).
 features:
-  - All Volume related panels in Horizon that previously used the term "GB" and "gigabyte" have been
+  - All Volume related panels in Horizon that previously used the term "GB" and
-    replaced with 'GiB' and 'gibibyte'.
+    "gigabyte" have been replaced with 'GiB' and 'gibibyte'.
 issues:
-  - There are also some Nova related panels (e.g. "Instances") that reference storage size in "GB".
+  - There are also some Nova related panels (e.g. "Instances") that reference
-    These panels will be addressed in subsequent patches.
+    storage size in "GB". These panels will be addressed in subsequent patches.
 fixes:
-  - blueprint gb-to-gib-conversion <https://blueprints.launchpad.net/horizon/+spec/gb-to-gib-conversion/>
+  - blueprint gb-to-gib-conversion <https://blueprints.launchpad.net/horizon/+spec/gb-to-gib-conversion/>

releasenotes/notes/global-class-name-convention-71ff68913c39b800.yaml

@@ -6,4 +6,5 @@ prelude: >
     camelcasing, to match with Bootstrap's convention.
 deprecations:
   - All instances of HTML class 'd3_pie_chart_usage' to 'pie-chart-usage'.
-    All instances of HTML class 'd3_pie_chart_distribution' to 'pie-chart-distribution'.
+    All instances of HTML class 'd3_pie_chart_distribution' to
+    'pie-chart-distribution'.

releasenotes/notes/keystone-federation-idp-d4456dd3b3081a53.yaml

@@ -3,7 +3,8 @@ features:
   - >
    [`blueprint keystone-federation-idp <https://blueprints.launchpad.net/horizon/+spec/keystone-federation-idp>`_]
    Add support for managing keystone identity provider. To enable the panel,
-   set ``OPENSTACK_KEYSTONE_FEDERATION_MANAGEMENT`` in the local_settting.py to True.
+   set ``OPENSTACK_KEYSTONE_FEDERATION_MANAGEMENT`` in the local_settting.py to
+   True.
   - >
    [`blueprint keystone-federation-mapping <https://blueprints.launchpad.net/horizon/+spec/keystone-federation-mapping>`_]
    Add basic support for managing keystone federation mapping.

releasenotes/notes/workflow-step-policy-1ca99b0249294337.yaml

@@ -2,4 +2,4 @@
 features:
   - Added policy support to the angular workflow service so each step in a
     workflow can specify a policy check that must pass in order for the step
-    to be displayed.
+    to be displayed.

releasenotes/source/icehouse.rst

@@ -137,7 +137,9 @@ For more information see
 Integration Test Framework
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Horizon now supports running integration tests against a working devstack system. There is a limited test suite, but this a great step forward and allows full integration testing.
+Horizon now supports running integration tests against a working devstack
+system. There is a limited test suite, but this a great step forward and allows
+full integration testing.
 
 Django 1.6 Support
 ~~~~~~~~~~~~~~~~~~

releasenotes/source/kilo.rst

@@ -26,9 +26,9 @@ Key New Features
   workflow has been implemented in AngularJS to address usability issues in the
   existing launch instance workflow. Due to the late inclusion date and limited
   testing, this feature is marked as beta for Kilo and not enabled by default.
-  To use the new workflow, the following change to local_settings.py is required:
+  To use the new workflow, the following change to local_settings.py is
-  ``LAUNCH_INSTANCE_NG_ENABLED = True``. Additionally, you can disable the
+  required: ``LAUNCH_INSTANCE_NG_ENABLED = True``. Additionally, you can disable
-  default launch instance wizard with the following:
+  the default launch instance wizard with the following:
   ``LAUNCH_INSTANCE_LEGACY_ENABLED = False``. This new work is a view into
   future development in Horizon.
 

test-requirements.txt

@@ -11,6 +11,7 @@ hacking!=0.13.0,<0.14,>=0.12.0 # Apache-2.0
 #
 coverage!=4.4,>=4.0 # Apache-2.0
 django-nose>=1.4.4 # BSD
+doc8 # Apache-2.0
 flake8-import-order==0.12 # LGPLv3
 mock>=2.0 # BSD
 mox3!=0.19.0,>=0.7.0 # Apache-2.0

tox.ini

@@ -17,13 +17,11 @@ deps =
   -r{toxinidir}/requirements.txt
   -r{toxinidir}/test-requirements.txt
 commands =
-  docs: sphinx-build -W -b html doc/source doc/build/html
   horizon: {envpython} {toxinidir}/manage.py test --settings=horizon.test.settings {posargs}
   manage: {envpython} {toxinidir}/manage.py {posargs}
   py27: {[unit_tests]commands}
   py35: {[unit_tests]commands}
   openstack_dashboard: {envpython} {toxinidir}/manage.py test --settings=openstack_dashboard.test.settings {posargs}
-  releasenotes: sphinx-build -a -E -W -d releasenotes/build/doctrees -b html releasenotes/source releasenotes/build/html
   runserver: {envpython} {toxinidir}/manage.py runserver {posargs}
   venv: {posargs}
 
@@ -127,6 +125,16 @@ commands =
   pip install -U {env:TOX_EXTRA_DEPS:}
   {[unit_tests]commands}
 
+[testenv:docs]
+commands =
+  doc8 doc/source
+  sphinx-build -W -b html doc/source doc/build/html
+
+[testenv:releasenotes]
+commands =
+  doc8 releasenotes/source releasenotes/notes
+  sphinx-build -a -E -W -d releasenotes/build/doctrees -b html releasenotes/source releasenotes/build/html
+
 [flake8]
 exclude = .venv,.git,.tox,dist,*lib/python*,*egg,build,panel_template,dash_template,local_settings.py,*/local/*,*/test/test_plugins/*,.ropeproject,node_modules
 ignore =
@@ -139,3 +147,14 @@ import-order-style = pep8
 
 [hacking]
 local-check-factory = horizon.hacking.checks.factory
+
+[doc8]
+# File extensions to check
+extensions = .rst, .yaml
+# Maximal line length should be 80 but we have some overlong lines.
+# Let's not get far more in.
+max-line-length = 80
+# Disable some doc8 checks:
+# D000: Check RST validity
+# - cannot handle "none" for code-block directive
+ignore = D000