diff --git a/doc/source/configuration/branding.rst b/doc/source/configuration/branding.rst index c71b42ad80..3ccf9c3596 100644 --- a/doc/source/configuration/branding.rst +++ b/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. -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 ~~~~~~~~~~~ diff --git a/doc/source/configuration/customizing.rst b/doc/source/configuration/customizing.rst index c15b101e30..89ff91624e 100644 --- a/doc/source/configuration/customizing.rst +++ b/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/ -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 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 just after the default Horizon meta tags. .. _Font Awesome: https://fortawesome.github.io/Font-Awesome/ diff --git a/doc/source/configuration/pluggable_panels.rst b/doc/source/configuration/pluggable_panels.rst index 90c88b1d48..aa94cc6325 100644 --- a/doc/source/configuration/pluggable_panels.rst +++ b/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 -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' diff --git a/doc/source/configuration/settings.rst b/doc/source/configuration/settings.rst index f6ab5bfe95..4fb6185d88 100644 --- a/doc/source/configuration/settings.rst +++ b/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 -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:///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:///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 -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/configuration/themes.rst b/doc/source/configuration/themes.rst index 2ea0606ca7..05f897ce71 100644 --- a/doc/source/configuration/themes.rst +++ b/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 -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. diff --git a/doc/source/contributor/contributing.rst b/doc/source/contributor/contributing.rst index 2aa2a6884c..73e669e763 100644 --- a/doc/source/contributor/contributing.rst +++ b/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//__init__.py` - file is up to date, especially the `BUILD`. +1. Ensure the version information in the + `xstatic/pkg//__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 ----------- diff --git a/doc/source/contributor/quickstart.rst b/doc/source/contributor/quickstart.rst index 66120a3da3..de8856dc50 100644 --- a/doc/source/contributor/quickstart.rst +++ b/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 -process +Inside of ``dashboard.py`` you would have a class definition and the +registration process .. code-block:: python diff --git a/doc/source/contributor/ref/tables.rst b/doc/source/contributor/ref/tables.rst index b1bc2d2ad9..d4a5bd2318 100644 --- a/doc/source/contributor/ref/tables.rst +++ b/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 -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: diff --git a/doc/source/contributor/testing.rst b/doc/source/contributor/testing.rst index 0ec784ff44..051f5ed61f 100644 --- a/doc/source/contributor/testing.rst +++ b/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 - $ tox -e py27 -- openstack_dashboard.dashboards.identity.users.tests:UsersViewTests.test_index +.. 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 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/``. 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 ============= diff --git a/doc/source/contributor/topics/angularjs.rst b/doc/source/contributor/topics/angularjs.rst index 2f8030fd2f..029bf50502 100644 --- a/doc/source/contributor/topics/angularjs.rst +++ b/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 -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 /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 /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/.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:: diff --git a/doc/source/contributor/topics/javascript_testing.rst b/doc/source/contributor/topics/javascript_testing.rst index 5afc56c51b..f727cc25d5 100644 --- a/doc/source/contributor/topics/javascript_testing.rst +++ b/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`_ -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 ``/index.html`` in a browser to view the reports. +(dashboard tests). Load ``/index.html`` in a browser to view the +reports. Writing Tests ============= diff --git a/doc/source/contributor/topics/packaging.rst b/doc/source/contributor/topics/packaging.rst index b597355aa9..a2865ffa7b 100644 --- a/doc/source/contributor/topics/packaging.rst +++ b/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.`` diff --git a/doc/source/contributor/topics/policy.rst b/doc/source/contributor/topics/policy.rst index b7653a1652..1c894b9746 100644 --- a/doc/source/contributor/topics/policy.rst +++ b/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' -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"]] } diff --git a/doc/source/contributor/topics/testing.rst b/doc/source/contributor/topics/testing.rst index 5e82fac9a5..5d1e07cd94 100644 --- a/doc/source/contributor/topics/testing.rst +++ b/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 -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 --------------- diff --git a/doc/source/contributor/tutorials/dashboard.rst b/doc/source/contributor/tutorials/dashboard.rst index b8f603ebe2..efe607acf9 100644 --- a/doc/source/contributor/tutorials/dashboard.rst +++ b/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, -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 @@ -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 diff --git a/doc/source/contributor/tutorials/plugin.rst b/doc/source/contributor/tutorials/plugin.rst index d610a7c68d..06e5959428 100644 --- a/doc/source/contributor/tutorials/plugin.rst +++ b/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 ```` additionally. + to ``ADD_INSTALLED_APPS``, ensure that you include its ```` + additionally. This comes from the combination of the following two reasons. diff --git a/doc/source/contributor/tutorials/table_actions.rst b/doc/source/contributor/tutorials/table_actions.rst index bd97b5db5f..e7e50e2d6c 100644 --- a/doc/source/contributor/tutorials/table_actions.rst +++ b/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 -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 diff --git a/releasenotes/notes/admin-neutron-l3-agents-dd6274467572906b.yaml b/releasenotes/notes/admin-neutron-l3-agents-dd6274467572906b.yaml index 30689bde48..16f7409f9b 100644 --- a/releasenotes/notes/admin-neutron-l3-agents-dd6274467572906b.yaml +++ b/releasenotes/notes/admin-neutron-l3-agents-dd6274467572906b.yaml @@ -2,7 +2,8 @@ features: - > [`blueprint 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. diff --git a/releasenotes/notes/bp-add-server-metadata-a5d5582966ef25c5.yaml b/releasenotes/notes/bp-add-server-metadata-a5d5582966ef25c5.yaml index a39637b4a6..9fd7b93b0f 100644 --- a/releasenotes/notes/bp-add-server-metadata-a5d5582966ef25c5.yaml +++ b/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. \ No newline at end of file + from the OS::Nova::Server namespace of the glance metadata definitions. diff --git a/releasenotes/notes/bp-admin-views-filter-first-5b0d8a02b1271135.yaml b/releasenotes/notes/bp-admin-views-filter-first-5b0d8a02b1271135.yaml index a529d5069a..b94b215618 100644 --- a/releasenotes/notes/bp-admin-views-filter-first-5b0d8a02b1271135.yaml +++ b/releasenotes/notes/bp-admin-views-filter-first-5b0d8a02b1271135.yaml @@ -4,4 +4,4 @@ features: [`blueprint 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. \ No newline at end of file + into admin views. diff --git a/releasenotes/notes/bp-angular-template-overrides-9f05ffd61367245a.yaml b/releasenotes/notes/bp-angular-template-overrides-9f05ffd61367245a.yaml index 71cab054d6..086a570cfb 100644 --- a/releasenotes/notes/bp-angular-template-overrides-9f05ffd61367245a.yaml +++ b/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. \ No newline at end of file + as an additional file in the manifest.json file. diff --git a/releasenotes/notes/bp-cinder-consistency-groups-7cc98fda0ff3bb7a.yaml b/releasenotes/notes/bp-cinder-consistency-groups-7cc98fda0ff3bb7a.yaml index 14085981f7..26af0e6a23 100644 --- a/releasenotes/notes/bp-cinder-consistency-groups-7cc98fda0ff3bb7a.yaml +++ b/releasenotes/notes/bp-cinder-consistency-groups-7cc98fda0ff3bb7a.yaml @@ -2,12 +2,11 @@ features: - > [`blueprint 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. diff --git a/releasenotes/notes/bp-cinder-consistency-groups-b0aba555b1ed4a6c.yaml b/releasenotes/notes/bp-cinder-consistency-groups-b0aba555b1ed4a6c.yaml index 2ee0f30b39..1faac59a3c 100644 --- a/releasenotes/notes/bp-cinder-consistency-groups-b0aba555b1ed4a6c.yaml +++ b/releasenotes/notes/bp-cinder-consistency-groups-b0aba555b1ed4a6c.yaml @@ -3,10 +3,10 @@ features: - > [`blueprint 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. diff --git a/releasenotes/notes/bp-configurable-boot-sources-4ba89f3b2a927801.yaml b/releasenotes/notes/bp-configurable-boot-sources-4ba89f3b2a927801.yaml index e6ecb2fced..abba3c29a3 100644 --- a/releasenotes/notes/bp-configurable-boot-sources-4ba89f3b2a927801.yaml +++ b/releasenotes/notes/bp-configurable-boot-sources-4ba89f3b2a927801.yaml @@ -2,7 +2,7 @@ features: - > [`blueprint 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). diff --git a/releasenotes/notes/bp-edit-server-metadata-7e6b00946a2e793a.yaml b/releasenotes/notes/bp-edit-server-metadata-7e6b00946a2e793a.yaml index 409a755f0f..96de67d600 100644 --- a/releasenotes/notes/bp-edit-server-metadata-7e6b00946a2e793a.yaml +++ b/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) \ No newline at end of file + - Instance metadata can be updated + (https://blueprints.launchpad.net/horizon/+spec/edit-server-metadata) diff --git a/releasenotes/notes/bp-horizon-vendor-split-4451bc1988485957.yaml b/releasenotes/notes/bp-horizon-vendor-split-4451bc1988485957.yaml index 29f7137014..71be0f28e4 100644 --- a/releasenotes/notes/bp-horizon-vendor-split-4451bc1988485957.yaml +++ b/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. - 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 diff --git a/releasenotes/notes/bp-password-expires-validation-28b7ea155404b778.yaml b/releasenotes/notes/bp-password-expires-validation-28b7ea155404b778.yaml index d97c647ae3..3f77a5355d 100644 --- a/releasenotes/notes/bp-password-expires-validation-28b7ea155404b778.yaml +++ b/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. \ No newline at end of file + date. diff --git a/releasenotes/notes/bp-port-allowed-address-pairs-extension-a05c3a864f494b0c.yaml b/releasenotes/notes/bp-port-allowed-address-pairs-extension-a05c3a864f494b0c.yaml index 1f76b90c8a..baf3e3f24b 100644 --- a/releasenotes/notes/bp-port-allowed-address-pairs-extension-a05c3a864f494b0c.yaml +++ b/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. \ No newline at end of file + deleting, and listing address pairs for the current port. diff --git a/releasenotes/notes/drop-settings-enable-fireall-vpn-fad7c1a4cd96df2b.yaml b/releasenotes/notes/drop-settings-enable-fireall-vpn-fad7c1a4cd96df2b.yaml index f64b91cf2b..8df2f8feaf 100644 --- a/releasenotes/notes/drop-settings-enable-fireall-vpn-fad7c1a4cd96df2b.yaml +++ b/releasenotes/notes/drop-settings-enable-fireall-vpn-fad7c1a4cd96df2b.yaml @@ -7,6 +7,6 @@ upgrade: use ``REMOVE_PANEL`` of `the Pluggable Panel mechanism ` 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. diff --git a/releasenotes/notes/dynamic-themes-b6b02238e47b99f8.yaml b/releasenotes/notes/dynamic-themes-b6b02238e47b99f8.yaml index e240eb6d1b..230641952c 100644 --- a/releasenotes/notes/dynamic-themes-b6b02238e47b99f8.yaml +++ b/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. \ No newline at end of file + - The setting DEFAULT_THEME_PATH is now deprecated. diff --git a/releasenotes/notes/extensible-service-a8689c89a71f8961.yaml b/releasenotes/notes/extensible-service-a8689c89a71f8961.yaml index 240928b9d4..18d273985a 100644 --- a/releasenotes/notes/extensible-service-a8689c89a71f8961.yaml +++ b/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. \ No newline at end of file + angular Launch Instance workflow. diff --git a/releasenotes/notes/gb-to-gib-conversion-8a91839030a2f570.yaml b/releasenotes/notes/gb-to-gib-conversion-8a91839030a2f570.yaml index 9bb41fc5ee..9b52a795e8 100644 --- a/releasenotes/notes/gb-to-gib-conversion-8a91839030a2f570.yaml +++ b/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 - 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 \ No newline at end of file + - blueprint gb-to-gib-conversion diff --git a/releasenotes/notes/global-class-name-convention-71ff68913c39b800.yaml b/releasenotes/notes/global-class-name-convention-71ff68913c39b800.yaml index 72d20618c6..b2f1952ce4 100644 --- a/releasenotes/notes/global-class-name-convention-71ff68913c39b800.yaml +++ b/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'. diff --git a/releasenotes/notes/keystone-federation-idp-d4456dd3b3081a53.yaml b/releasenotes/notes/keystone-federation-idp-d4456dd3b3081a53.yaml index 1e1462ad45..5c86a1c4e7 100644 --- a/releasenotes/notes/keystone-federation-idp-d4456dd3b3081a53.yaml +++ b/releasenotes/notes/keystone-federation-idp-d4456dd3b3081a53.yaml @@ -3,7 +3,8 @@ features: - > [`blueprint 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 `_] Add basic support for managing keystone federation mapping. diff --git a/releasenotes/notes/workflow-step-policy-1ca99b0249294337.yaml b/releasenotes/notes/workflow-step-policy-1ca99b0249294337.yaml index 8f2225591e..0bac2a6287 100644 --- a/releasenotes/notes/workflow-step-policy-1ca99b0249294337.yaml +++ b/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. \ No newline at end of file + to be displayed. diff --git a/releasenotes/source/icehouse.rst b/releasenotes/source/icehouse.rst index e3427485f6..0203080b63 100644 --- a/releasenotes/source/icehouse.rst +++ b/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 ~~~~~~~~~~~~~~~~~~ diff --git a/releasenotes/source/kilo.rst b/releasenotes/source/kilo.rst index fc4e7c1a86..73b7300d99 100644 --- a/releasenotes/source/kilo.rst +++ b/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: - ``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. diff --git a/test-requirements.txt b/test-requirements.txt index cf83b72dd3..f54dd7845c 100644 --- a/test-requirements.txt +++ b/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 diff --git a/tox.ini b/tox.ini index 91ceac6c9a..433e46fefb 100644 --- a/tox.ini +++ b/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