openstack/horizon
Code Issues Proposed changes

Use doc8 check

Browse Source 
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
This commit is contained in:
Akihiro Motoki 2017-07-08 20:53:45 +00:00
parent 172b16d515
commit 497cae2b57
39 changed files with 342 additions and 258 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/source/configuration/branding.rst
View File

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

67
doc/source/configuration/customizing.rst
View File

@ -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/
folder. These files are loaded based upon the filename order, with space left for more
files to be added. There are some example files available within this folder, with the
.example suffix added. Developers and deployers should strive to use this method of
customization as much as possible, and support for this is given preference over more
exotic methods such as monkey patching and overrides files.
Default Horizon panels are loaded based upon files within the
openstack_dashboard/enabled/ folder. These files are loaded based upon the
filename order, with space left for more files to be added. There are some
example files available within this folder, with the .example suffix
added. Developers and deployers should strive to use this method of
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
yet customizable via configuration settings. This file can perform monkey patching and
other forms of customization which are not possible via the enabled folder's customization
method.
Horizon has a global overrides mechanism available to perform customizations
that are not yet customizable via configuration settings. This file can perform
monkey patching and other forms of customization which are not possible via the
enabled folder's customization method.
This method of customization is meant to be available for deployers of Horizon, and use of
this should be avoided by Horizon plugins at all cost. Plugins needing this level of
monkey patching and flexibility should instead look for changing their __init__.py file
and performing customizations through other means.
This method of customization is meant to be available for deployers of Horizon,
and use of this should be avoided by Horizon plugins at all cost. Plugins
needing this level of monkey patching and flexibility should instead look for
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
the resource type registry service. The ``extensibleService`` allows certain Horizon
elements to be extended dynamically, including add, remove, and replace. The
``resourceTypeRegistry`` service provides methods to set and get information
pertaining to a resource type object. We use Heat type names like ``OS::Glance::Image``
as our reference name.
in the Horizon framework that make this possible are the extensibility service
and the resource type registry service. The ``extensibleService`` allows
certain Horizon elements to be extended dynamically, including add, remove, and
replace. The ``resourceTypeRegistry`` service provides methods to set and get
information pertaining to a resource type object. We use Heat type names like
``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.
It gives developers a quick way to build a new table or change an existing table.
templates so we do not need to write boilerplate HTML and controller code. It
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
Images Panel.::
This is a sample module file to demonstrate how to make some customizations to
the Images Panel.::
(function() {
'use strict';
@ -287,9 +290,9 @@ Images Panel.::
}
})();
Additionally, you should have content defined in ``detail.html`` and ``drawer.html``,
as well as define the ``surpriseService`` which is based off the ``actions``
directive and needs allowed and perform methods defined.
Additionally, you should have content defined in ``detail.html`` and
``drawer.html``, as well as define the ``surpriseService`` which is based off
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
can be overridden.
template ``openstack_dashboard/templates/base.html`` defines multiple blocks
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
inserted into the page's <head> just after the default Horizon meta tags.
them in the ``horizon/_custom_meta.html`` file. The contents of this file will
be inserted into the page's <head> just after the default Horizon meta tags.
.. _Font Awesome: https://fortawesome.github.io/Font-Awesome/

34
doc/source/configuration/pluggable_panels.rst
View File

@ -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
loaded on every page. This is needed for AngularJS modules that are referenced in
``ADD_ANGULAR_MODULES`` and therefore need to be included in every page.
A list of javascript source files to be included in the compressed set of files
that are loaded on every page. This is needed for AngularJS modules that are
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.
Jasmine is a behavior-driven development framework for testing JavaScript code.
A list of javascript spec files to include for integration with the Jasmine
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
automatically discovered from the `static` folder in each apps listed in ADD_INSTALLED_APPS.
If set to ``True``, JavaScript files and static angular html template files
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
`.module.js` listed first, followed by other JavaScript source files.
JavaScript source files will be ordered based on naming convention: files with
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
`.mock.js` listed first, followed by files with extension `.spec.js`.
JavaScript files for testing will also be ordered based on naming convention:
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
appended to the auto-discovered files.
If ADD_JS_FILES and/or ADD_JS_SPEC_FILES are also specified, files manually
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
``openstack_dashboard/local/enabled/_80_admin_default_panel.py`` with the
To change the default panel of Admin dashboard to Instances panel, create a
file ``openstack_dashboard/local/enabled/_80_admin_default_panel.py`` with the
following content::
PANEL = 'instances'

62
doc/source/configuration/settings.rst
View File

@ -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
and the user will be asked to provide a search criteria first (in case no search
criteria was provided) before loading any data.
If the dict key-value is True, when the view loads, an empty table will be
rendered and the user will be asked to provide a search criteria first (in case
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
loaded on every page. This is needed for AngularJS modules that are referenced in
``angular_modules`` and therefore need to be include in every page.
A list of javascript source files to be included in the compressed set of files
that are loaded on every page. This is needed for AngularJS modules that are
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.
Jasmine is a behavior-driven development framework for testing JavaScript code.
A list of javascript spec files to include for integration with the Jasmine
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
purposes, other OpenStack components that are expected to profile themselves
with osprofiler using the data from the request that Horizon initiated must
share a common set of keys with the ones in Horizon config. List of keys is
used so that security keys could be changed in non-obtrusive manner for every
component in the cloud. Example: ``"keys": ["SECRET_KEY", "MORE_SECRET_KEY"]``.
the profiler data contained in request headers. Encryption is used for
security purposes, other OpenStack components that are expected to profile
themselves with osprofiler using the data from the request that Horizon
initiated must share a common set of keys with the ones in Horizon
config. List of keys is used so that security keys could be changed in
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.
The ``direct`` setting requires a modern web browser, network access from the
browser to the public Glance endpoint, and CORS support to be enabled on the
Glance API service. Without CORS support, the browser will forbid the PUT request
to a location different than the Horizon server. To enable CORS support for Glance
API service, you will need to edit [cors] section of glance-api.conf file (see
`here`_ how to do it). Set `allowed_origin` to the full hostname of Horizon
web-server (e.g. http://<HOST_IP>/dashboard) and restart glance-api process.
is the preferred mode, but due to the following requirements it is not the
default. The ``direct`` setting requires a modern web browser, network access
from the browser to the public Glance endpoint, and CORS support to be enabled
on the Glance API service. Without CORS support, the browser will forbid the
PUT request to a location different than the Horizon server. To enable CORS
support for Glance API service, you will need to edit [cors] section of
glance-api.conf file (see `here`_ how to do it). Set `allowed_origin` to the
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
~~~~~~~~~~~~~~~~~~~~~~~
@ -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
attributes to Identity API attributes. This extension requires v3.0+ of the
Identity API.
Identity Providers (IdPs) and establish a set of rules to map federation
protocol attributes to Identity API attributes. This extension requires v3.0+
of the Identity API.
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

18
doc/source/configuration/themes.rst
View File

@ -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
variables file at ``openstack_dashboard/static/dashboard/scss/_variables.scss``.
For a full list of the Dashboard SCSS variables that can be changed,
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
``darkly`` theme::
`/horizon/lib/`. The following is an example of how to inherit from
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
constrained to fit within the height of nav. You can customize the height of
the top navigation bar by customizing the SCSS variable: ``$navbar-height``.
image used is larger than the height of the top navigation, then the image will
be constrained to fit within the height of nav. You can customize the 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.

79
doc/source/contributor/contributing.rst
View File

@ -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`
file is up to date, especially the `BUILD`.
1. Ensure the version information in the
`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
performed. One will be created automatically by the release process in the
``openstack/requirements`` project with the topic `new-release`_. You should -1 that
patch until you are confident Horizon does not break (or you have generated a patch to
fix Horizon for that release.) If no upper-constraints.txt patch is automatically
generated, ensure the releases yaml file created in the `releases repository`_ has the
1. Look for the `upper-constraints.txt`_ edit related to the xstatic release
that was just performed. One will be created automatically by the release
process in the ``openstack/requirements`` project with the topic
`new-release`_. You should -1 that patch until you are confident Horizon
does not break (or you have generated a patch to fix Horizon for that
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.
3. Set the environment variable `UPPER_CONSTRAINTS_FILE` to the edited 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.
2. Pull that patch down so you have the edited upper-constraints.txt file
locally.
3. Set the environment variable `UPPER_CONSTRAINTS_FILE` to the edited
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
from a Horizon developer will indicate to the requirements 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,
use a Depends-On: referencing the upper-constraints.txt review. This will cause the OpenStack
testing infrastructure to pull in your updated xstatic package as well.
3. Merge the upper-constraints.txt patch and the Horizon patch noting that Horizon's gate may be
broken in the interim between these steps, so try to minimise any delay there. With the
Depends-On it's actually safe to +W the Horizon patch, which will be held up until the
related upper-constraints.txt patch merges.
4. Once the upper-constraints.txt patch merges, you should propose a patch to 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.
1. Continue to -1 the upper-constraints.txt patch above until this process is
complete. A +1 from a Horizon developer will indicate to the requirements
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, use a Depends-On: referencing the upper-constraints.txt
review. This will cause the OpenStack testing infrastructure to pull in your
updated xstatic package as well.
3. Merge the upper-constraints.txt patch and the Horizon patch noting that
Horizon's gate may be broken in the interim between these steps, so try to
minimise any delay there. With the Depends-On it's actually safe to +W the
Horizon patch, which will be held up until the related upper-constraints.txt
patch merges.
4. Once the upper-constraints.txt patch merges, you should propose a patch to
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
-----------

4
doc/source/contributor/quickstart.rst
View File

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

9
doc/source/contributor/ref/tables.rst
View File

@ -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
API and appearance, and generally you don't have to reinvent the wheel or
copy-and-paste every time you need a new table!
correctly and consistently, table-level and row-level actions all have a
consistent API and appearance, and generally you don't have to reinvent the
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:

19
doc/source/contributor/testing.rst
View File

@ -85,7 +85,9 @@ 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:
.. code-block:: console
$ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests
$ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests.test_index
@ -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
=============

58
doc/source/contributor/topics/angularjs.rst
View File

@ -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
directory or file with ``eslint file.js``.
horizon root directory with ``tox -e npm -- lint``, or alternatively on a
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
broken out as a reusable utility or widget.
When adding code to horizon, consider whether it is dashboard-specific or
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
for the ``Project`` dashboard's ``Container`` panel and includes:
enabled file. For example, `_1920_project_containers_panel.py` is the enabled
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
includes any launch instance styling:
example, ``project.scss`` would includes the ``workflow`` SCSS file, which in
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.
This provides namespace isolation for modules and services, which makes
dependency injection clearer. It also reduces code conflicts where two
Horizon Angular modules use names that map to the source code directory
structure. This provides namespace isolation for modules and services, which
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
with ``tox -e runserver`` from the horizon root directory; by default, this will
run the development server at ``http://localhost:8000``.
1. Open <dev_server_ip:port>/jasmine in a browser. The development server can
be run with ``tox -e runserver`` from the horizon root directory; by
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
part of the upstream horizon project.
horizon, using AngularJS. A panel may be included with the plugin system, or it
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
the folder for the dashboard/panel/panel groups Python package.
- 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``.
- Static files should be put in a ``static/`` folder, which should be found
directly under the folder for the dashboard/panel/panel groups Python
package.
- 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
inclusion is the same as the Upstream process.
Add a new panel/ panel group/ dashboard (See :ref:`tutorials-dashboard`).
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
used to create forms from that schema. Horizon adds some functionality on top of
that to make things even easier through ``ModalFormService`` which will open a
modal with the form inside.
`JSON schemas`_ are used to define model layout and then `angular-schema-form`_
is used to create forms from that schema. Horizon adds some functionality on
top of that to make things even easier through ``ModalFormService`` which will
open a modal with the form inside.
A very simple example::

19
doc/source/contributor/topics/javascript_testing.rst
View File

@ -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`_
below for more detail on this.
that they are testing. See the :ref:`js_file_structure` section or the
`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.
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
have the jasmine report you may click on the title of an individual test to
browser to run individual tests to see where the tests are specifically
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 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
places where the code breaks.
lines of code where you wish to break the code. This will then show you the
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
=============

5
doc/source/contributor/topics/policy.rst
View File

@ -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'
in file 'openstack_dashboard/static/app/core/cloud-services/hz-if-policies.directive.js'.
The fourth way to add a role based check is in html files. Use angular
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"]] }

18
doc/source/contributor/topics/testing.rst
View File

@ -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
across horizon that are related to your patch.
functions in the patch that have failed, but more that there are not enough
tests across horizon that are related to your patch.
The coverage reports may be found in the 'cover' directory. There's a subdirectory
for horizon and openstack_dashboard, and then under a directory for the browser
used to run the tests you should find an ``index.html``. This can then be viewed
to see the coverage details.
The coverage reports may be found in the 'cover' directory. There's a
subdirectory for horizon and openstack_dashboard, and then under a directory
for the browser used to run the tests you should find an ``index.html``. This
can then be viewed to see the coverage details.
In this scenario you may need to submit a secondary patch to address test coverage
for another function within horizon to ensure tests rise above the coverage
threshold and your original patch can pass the necessary tests.
In this scenario you may need to submit a secondary patch to address test
coverage for another function within horizon to ensure tests rise above the
coverage threshold and your original patch can pass the necessary tests.
Common pitfalls
---------------

28
doc/source/contributor/tutorials/dashboard.rst
View File

@ -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,
any module name listed in the ``panels`` attribute on the dashboard class will
be auto-discovered by looking for the ``panel.py`` file in a corresponding
directory (the details are a bit magical, but have been thoroughly vetted in
Django's admin codebase).
The ``panel.py`` file referenced above has a special meaning.
Within a dashboard, any module name listed in the ``panels`` attribute on the
dashboard class will be auto-discovered by looking for the ``panel.py`` file in
a corresponding directory (the details are a bit magical, but have been
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
the vast majority of 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 the ``mypanel`` directory and add the
following code::
Horizon provides a :class:`~horizon.forms.SelfHandlingForm`
:class:`~horizon.tables.DataTable` class which simplifies the vast majority of
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
the ``mypanel`` directory and add the 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
the following::
After importing the proper package, the completed ``views.py`` file now looks
like the following::
from horizon import tabs

3
doc/source/contributor/tutorials/plugin.rst
View File

@ -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.

30
doc/source/contributor/tutorials/table_actions.rst
View File

@ -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
an action and form definitions, as well as changes to the view, urls, and table.
This tutorial covers how to add a more complex action to a table, one that
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``
button.
and will create that snapshot when the form is closed using the ``Create
snapshot`` button.
Defining the view
=================
To define the view, we must create a view class, along with the template (``HTML``)
file and the form class for that view.
To define the view, we must create a view class, along with the template
(``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
some of the details involved in creating a form. Our form will derive from this
class, adding a character field to allow the user to specify a name for the
snapshot, and handling the successful closure of the form by calling the nova
api to create the snapshot.
Horizon provides a :class:`~horizon.forms.base.SelfHandlingForm` class which
simplifies some of the details involved in creating a form. Our form will
derive from this class, adding a character field to allow the user to specify
a name for the snapshot, and handling the successful closure of the form by
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
view that will contain a modal form.
:class:`~horizon.forms.views.ModalFormView` class which simplifies the creation
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

9
releasenotes/notes/admin-neutron-l3-agents-dd6274467572906b.yaml
View File

@ -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
links / views to see what routers reside on what hosts. In addition, the admin view of routers
now also provides a list of where the router is hosted and the link to see what other routers are sharing
the same host.
Add support for managing neutron L3 agent hosts. The admin screen for system
information now provides links / views to see what routers reside on what
hosts. In addition, the admin view of routers now also provides a list of
where the router is hosted and the link to see what other routers are
sharing the same host.

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

@ -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
Consistency Groups, and the second tab will display Consistency Group Snapshots.
Consistency Groups (CG) contain existing volumes, and allow the user to perform
actions on the volumes in one step. Actions include: create/update/delete CGs,
snapshot all volumes in a CG, 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 policy file, and
by default, all actions are disabled.
This feature adds 2 new tabs to the Project Volumes panel. The first tab
will display Consistency Groups, and the second tab will display
Consistency Group Snapshots. Consistency Groups (CG) contain existing
volumes, and allow the user to perform actions on the volumes in one step.
Actions include: create/update/delete CGs, snapshot all volumes in a CG,
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
policy file, and by default, all actions are disabled.

12
releasenotes/notes/bp-cinder-consistency-groups-b0aba555b1ed4a6c.yaml
View File

@ -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
actions on the volumes in one step. Actions include: create a CG, manage volumes
associated with the CG, update a CG, and delete a CGs. Note that a CG can not be
deleted if it contains any volumes.
Consistency Groups (GG) contain existing volumes, and allow the user to
perform actions on the volumes in one step. Actions include: create a CG,
manage volumes associated with the CG, update a CG, and delete a CGs. Note
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
by default, all actions are disabled.
- Policies associated with Consistency Groups exist in the Cinder policy
file, and by default, all actions are disabled.

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

@ -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
Launch Instance modal by adding 4 new settings to
LAUNCH_INSTANCE_DEFAULTS (disable_image, disable_instance_snapshot, disable_volume,
disable_volume_snapshot).
Allows administrators to restrict which sources are available to boot from
in the Launch Instance modal by adding 4 new settings to
LAUNCH_INSTANCE_DEFAULTS (disable_image, disable_instance_snapshot,
disable_volume, disable_volume_snapshot).

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

@ -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)

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

@ -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.
It is now available as a separate plugin at https://github.com/bigswitch/horizon-bsn
As part of the horizon-vendor-split work, we drop the extension from
upstream horizon. It is now available as a separate plugin at
https://github.com/bigswitch/horizon-bsn

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

@ -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
panels if not available, so in most cases you do not need to take care of
the change.
FWaaS v1 and/or VPNaaS in your Neutron deploymennt and disables
corresponding panels if not available, so in most cases you do not need to
take care of the change.

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

@ -1,12 +1,12 @@
---
prelude: >
Cinder defines storage size in gibibytes (GiB), which is inconsistent with Horizon panels that
show/request storage size in gigabytes (GB).
Cinder defines storage size in gibibytes (GiB), which is inconsistent with
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
replaced with 'GiB' and 'gibibyte'.
- All Volume related panels in Horizon that previously used the term "GB" and
"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".
These panels will be addressed in subsequent patches.
- There are also some Nova related panels (e.g. "Instances") that reference
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/>

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

@ -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'.

3
releasenotes/notes/keystone-federation-idp-d4456dd3b3081a53.yaml
View File

@ -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.

4
releasenotes/source/icehouse.rst
View File

@ -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
~~~~~~~~~~~~~~~~~~

6
releasenotes/source/kilo.rst
View File

@ -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:
``LAUNCH_INSTANCE_NG_ENABLED = True``. Additionally, you can disable the
default launch instance wizard with the following:
To use the new workflow, the following change to local_settings.py is
required: ``LAUNCH_INSTANCE_NG_ENABLED = True``. Additionally, you can disable
the default launch instance wizard with the following:
``LAUNCH_INSTANCE_LEGACY_ENABLED = False``. This new work is a view into
future development in Horizon.

1
test-requirements.txt
View File

@ -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

23
tox.ini
View File

@ -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