openstack
/
horizon
Code Issues Proposed changes
horizon/doc/source/topics/settings.rst

2257 lines
69 KiB
ReStructuredText
Raw Blame History

==========================
Settings and Configuration
==========================
Introduction
============
Horizon's settings tend to fall into three categories:
* Horizon configuration options (contained in the ``HORIZON_CONFIG`` dict)
which are not OpenStack-specific and pertain only to the core framework.
* OpenStack-related settings which pertain to other projects/services and
are generally prefixed with ``OPENSTACK_`` in the settings file.
* Django settings (including common plugins like ``django-compressor``) which
can be (and should be) read about in their respective documentation.
What follows is an overview of the Horizon and OpenStack-specific settings
and a few notes on the Django-related settings.
.. note::
Prior to the Essex release of Horizon there were settings which controlled
whether features such as Object Storage/Swift or Networking/Neutron would be
enabled in the OpenStack Dashboard. This code has long since been removed
and those pre-Essex settings have no impact now.
In Essex and later, the Service Catalog returned by the Identity Service
after a user has successfully authenticated determines the dashboards and
panels that will be available within the OpenStack Dashboard. If you are not
seeing a particular service you expected make sure your Service Catalog is
configured correctly.
Horizon Settings
================
The following options are available in order to configure/customize the
behavior of your Horizon installation. All of them are contained in the
``HORIZON_CONFIG`` dictionary.
.. _dashboards:
``dashboards``
--------------
.. warning::
In OpenStack Dashboard configuration, we suggest **NOT** to use this
setting. Please specify the order of dashboard using the
:ref:`pluggable-settings-label`.
Both the pluggable dashboard mechanism (OpenStack Dashboard default) and
this setting ``dashboard`` configure the order of dashboards and
the setting ``dashboard`` precedes the pluggable dashboard mechanism.
Specifying the order in two places may cause confusion.
Please use this parameter only when the pluggable config is not used.
.. versionadded:: 2012.1(Essex)
Default: ``None``
Horizon Dashboards are automatically discovered in the following way:
* By adding a configuration file to the ``openstack_dashboard/local/enabled``
directory (for more information see :ref:`pluggable-settings-label`).
This is the default way in OpenStack Dashboard.
* By traversing Django's list of
`INSTALLED_APPS <https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-INSTALLED_APPS>`_
and importing any files that have the name ``"dashboard.py"`` and include
code to register themselves as a Horizon dashboard.
* For upstream development since Newton, please use ``ANGULAR_FEATURES`` setting to
toggle Angular panel features, instead of defining an enabled file for the
Angular panel. Then use ``settings.ANGULAR_FEATURES[<panel_name>]`` in your urls.py.
This enforces showing one service panel in the dashboard at a time.
By default, dashboards defined by ``openstack_dashboard/local/enabled`` are
displayed first in the alphabetical order of the config files, and then the
remaining dashboards discovered by traversing INSTALLED_APPS are displayed
in the alphabetical order.
If a list of ``dashboard`` slugs is provided in this setting, the supplied
ordering is applied to the list of discovered dashboards. If the list of
dashboard slugs is shorter than the number of discovered dashboards, the
remaining dashboards are appended in the default order described above.
The dashboards listed must be in a Python module which
is included in the ``INSTALLED_APPS`` list and on the Python path.
``default_dashboard``
---------------------
.. warning::
In OpenStack Dashboard configuration, we suggest **NOT** to use this
setting. Please specify the order of dashboard using the
:ref:`pluggable-settings-label`.
The default dashboard can be configured via both the pluggable
dashboard mechanism (OpenStack Dashboard default) and this setting
``default_dashboard``, and if both are specified, the setting
by the pluggable dashboard mechanism will be used.
Specifying the default dashboard in two places may cause confusion.
Please use this parameter only when the pluggable config is not used.
.. versionadded:: 2012.1(Essex)
Default: ``None``
The slug of the dashboard which should act as the first-run/fallback dashboard
whenever a user logs in or is otherwise redirected to an ambiguous location.
``user_home``
-------------
.. versionadded:: 2012.1(Essex)
Default: ``settings.LOGIN_REDIRECT_URL``
This can be either a literal URL path (such as the default), or Python's
dotted string notation representing a function which will evaluate what URL
a user should be redirected to based on the attributes of that user.
``ajax_queue_limit``
--------------------
.. versionadded:: 2012.1(Essex)
Default: ``10``
The maximum number of simultaneous AJAX connections the dashboard may try
to make. This is particularly relevant when monitoring a large number of
instances, volumes, etc. which are all actively trying to update/change state.
``ajax_poll_interval``
----------------------
.. versionadded:: 2012.1(Essex)
Default: ``2500``
How frequently resources in transition states should be polled for updates,
expressed in milliseconds.
``auto_fade_alerts``
--------------------
.. versionadded:: 2013.2(Havana)
Defaults: ``{'delay': [3000], 'fade_duration': [1500], 'types': []}``
If provided, will auto-fade the alert types specified. Valid alert types
include: ['alert-default', 'alert-success', 'alert-info', 'alert-warning',
'alert-danger'] Can also define the delay before the alert fades and the fade
out duration.
``bug_url``
-----------
.. versionadded:: 9.0.0(Mitaka)
Default: ``None``
If provided, a "Report Bug" link will be displayed in the site header which
links to the value of this setting (ideally a URL containing information on
how to report issues).
``help_url``
------------
.. versionadded:: 2012.2(Folsom)
Default: ``None``
If provided, a "Help" link will be displayed in the site header which links
to the value of this setting (ideally a URL containing help information).
``exceptions``
--------------
.. versionadded:: 2012.1(Essex)
Default: ``{'unauthorized': [], 'not_found': [], 'recoverable': []}``
A dictionary containing classes of exceptions which Horizon's centralized
exception handling should be aware of. Based on these exception categories,
Horizon will handle the exception and display a message to the user.
``modal_backdrop``
------------------
.. versionadded:: 2014.2(Kilo)
Default: ``"static"``
Controls how bootstrap backdrop element outside of modals looks and feels.
Valid values are ``"true"`` (show backdrop element outside the modal, close
the modal after clicking on backdrop), ``"false"`` (do not show backdrop
element, do not close the modal after clicking outside of it) and ``"static"``
(show backdrop element outside the modal, do not close the modal after
clicking on backdrop).
``disable_password_reveal``
---------------------------
.. versionadded:: 2015.1(Kilo)
Default: ``False``
Setting this to True will disable the reveal button for password fields,
including on the login form.
``password_validator``
----------------------
.. versionadded:: 2012.1(Essex)
Default: ``{'regex': '.*', 'help_text': _("Password is not accepted")}``
A dictionary containing a regular expression which will be used for password
validation and help text which will be displayed if the password does not
pass validation. The help text should describe the password requirements if
there are any.
This setting allows you to set rules for passwords if your organization
requires them.
``password_autocomplete``
-------------------------
.. versionadded:: 2013.1(Grizzly)
Default: ``"off"``
Controls whether browser autocompletion should be enabled on the login form.
Valid values are ``"on"`` and ``"off"``.
``simple_ip_management``
------------------------
.. versionadded:: 2013.1(Grizzly)
Default: ``True``
Enable or disable simplified floating IP address management.
"Simple" floating IP address management means that the user does not ever have
to select the specific IP addresses they wish to use, and the process of
allocating an IP and assigning it to an instance is one-click.
The "advanced" floating IP management allows users to select the floating IP
pool from which the IP should be allocated and to select a specific IP address
when associating one with an instance.
.. note::
Currently "simple" floating IP address management is not compatible with
Neutron. There are two reasons for this. First, Neutron does not support
the default floating IP pool at the moment. Second, a Neutron floating IP
can be associated with each VIF and we need to check whether there is only
one VIF for an instance to enable simple association support.
``angular_modules``
-------------------------
Default: ``[]``
A list of AngularJS modules to be loaded when Angular bootstraps. These modules
are added as dependencies on the root Horizon application ``horizon``.
``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.
``js_spec_files``
-------------------------
.. versionadded:: 2015.1(Kilo)
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.
OpenStack Settings (Partial)
============================
The following settings inform the OpenStack Dashboard of information about the
other OpenStack projects which are part of this cloud and control the behavior
of specific dashboards, panels, API calls, etc.
Most of the following settings are defined in
``openstack_dashboard/local/local_settings.py``, which should be copied from
``openstack_dashboard/local/local_settings.py.example``.
Since Mitaka, there is also a way to drop file snippets into
``openstack_dashboard/local/local_settings.d/``. These snippets must end with
``.py`` and must contain valid Python code. The snippets are loaded after
``local_settings.py`` is evaluated so you are able to override settings from
``local_settings.py`` without the need to change this file.
Snippets are evaluated in alphabetical order by file name.
It's good style to name the files in ``local_settings.d/`` like
``_ZZ_another_setting.py`` where ``ZZ`` is a number. The file must start with
an underscore (``_``) because Python can not load files starting with a number.
So given that you have 3 files, ``local_settings.py``,
``local_settings.d/_10_setting_one.py`` and ``local_settings.d/_20_settings_two.py``,
the settings from ``local_settings.py`` are evaluated first. Settings from
``local_settings.d/_10_settings_one.py`` override settings from ``local_settings.py``
and settings from ``local_settings.d/_20_settings_two.py`` override all other settings
because that's the file which is evaluated last.
``AUTHENTICATION_URLS``
-----------------------
.. versionadded:: 2015.1(Kilo)
Default: ``['openstack_auth.urls']``
A list of modules from which to collate authentication URLs from. The default
option adds URLs from the django-openstack-auth module however others will be
required for additional authentication mechanisms.
``API_RESULT_LIMIT``
--------------------
.. versionadded:: 2012.1(Essex)
Default: ``1000``
The maximum number of objects (e.g. Swift objects or Glance images) to display
on a single page before providing a paging element (a "more" link) to paginate
results.
``API_RESULT_PAGE_SIZE``
------------------------
.. versionadded:: 2012.2(Folsom)
Default: ``20``
Similar to ``API_RESULT_LIMIT``. This setting controls the number of items
to be shown per page if API pagination support for this exists.
``AVAILABLE_REGIONS``
---------------------
.. versionadded:: 2012.1(Essex)
Default: ``None``
A list of tuples which define multiple regions. The tuple format is
``('http://{{ keystone_host }}:5000/v2.0', '{{ region_name }}')``. If any regions
are specified the login form will have a dropdown selector for authenticating
to the appropriate region, and there will be a region switcher dropdown in
the site header when logged in.
You should also define ``OPENSTACK_KEYSTONE_URL`` to indicate which of
the regions is the default one.
``CONSOLE_TYPE``
----------------
.. versionadded:: 2013.2(Havana)
Default: ``"AUTO"``
This setting specifies the type of in-browser console used to access the
VMs.
Valid values are ``"AUTO"``(default), ``"VNC"``, ``"SPICE"``, ``"RDP"``,
``"SERIAL"``, and ``None``.
``None`` deactivates the in-browser console and is available in version
2014.2(Juno).
``"SERIAL"`` is available since 2015.1(Kilo).
``SWIFT_FILE_TRANSFER_CHUNK_SIZE``
----------------------------------
.. versionadded:: 2015.1(Kilo)
Default: ``512 * 1024``
This setting specifies the size of the chunk (in bytes) for downloading objects
from Swift. Do not make it very large (higher than several dozens of Megabytes,
exact number depends on your connection speed), otherwise you may encounter
socket timeout. The default value is 524288 bytes (or 512 Kilobytes).
``INSTANCE_LOG_LENGTH``
-----------------------
.. versionadded:: 2015.1(Kilo)
Default: ``35``
This setting enables you to change the default number of lines displayed for
the log of an instance.
Valid value must be a positive integer.
``CREATE_INSTANCE_FLAVOR_SORT``
-------------------------------
.. versionadded:: 2013.2(Havana)
Default: ``{'key':'ram'}``
When launching a new instance the default flavor is sorted by RAM usage in
ascending order.
You can customize the sort order by: id, name, ram, disk and vcpus.
Additionally, you can insert any custom callback function. You can also
provide a flag for reverse sort.
See the description in local_settings.py.example for more information.
This example sorts flavors by vcpus in descending order::
CREATE_INSTANCE_FLAVOR_SORT = {
'key':'vcpus',
'reverse': True,
}
.. _angular_features:
``ANGULAR_FEATURES``
--------------------
.. versionadded:: 10.0.0(Newton)
Default::
{
'images_panel': True,
'flavors_panel': False,
'users_panel': False,
'roles_panel': False,
'domains_panel': False
}
A dictionary of currently available AngularJS features. This allows simple
toggling of legacy or rewritten features, such as new panels, workflows etc.
.. note::
If you toggle 'domains_panel' to True, you also need to enable the setting
of OPENSTACK_KEYSTONE_DEFAULT_DOMAIN and add OPENSTACK_KEYSTONE_DEFAULT_DOMAIN
to REST_API_REQUIRED_SETTINGS.
.. _available_themes:
``AVAILABLE_THEMES``
--------------------
.. versionadded:: 9.0.0(Mitaka)
Default::
AVAILABLE_THEMES = [
('default', 'Default', 'themes/default'),
('material', 'Material', 'themes/material'),
]
This setting tells Horizon which themes to use.
A list of tuples which define multiple themes. The tuple format is
``('{{ theme_name }}', '{{ theme_label }}', '{{ theme_path }}')``.
The ``theme_name`` is the name used to define the directory which
the theme is collected into, under ``/{{ THEME_COLLECTION_DIR }}``.
It also specifies the key by which the selected theme is stored in
the browser's cookie.
The ``theme_label`` is the user-facing label that is shown in the
theme picker. The theme picker is only visible if more than one
theme is configured, and shows under the topnav's user menu.
By default, the ``theme path`` is the directory that will serve as
the static root of the theme and the entire contents of the directory
is served up at ``/{{ THEME_COLLECTION_DIR }}/{{ theme_name }}``.
If you wish to include content other than static files in a theme
directory, but do not wish that content to be served up, then you
can create a sub directory named ``static``. If the theme folder
contains a sub-directory with the name ``static``, then
``static/custom/static`` will be used as the root for the content
served at ``/static/custom``.
The static root of the theme folder must always contain a _variables.scss
file and a _styles.scss file. These must contain or import all the
bootstrap and horizon specific variables and styles which are used to style
the GUI. For example themes, see: /horizon/openstack_dashboard/themes/
Horizon ships with two themes configured. 'default' is the default theme,
and 'material' is based on Google's Material Design.
``DEFAULT_THEME``
-----------------
.. versionadded:: 9.0.0(Mitaka)
Default: ``"default"``
This setting tells Horizon which theme to use if the user has not
yet selected a theme through the theme picker and therefore set the
cookie value. This value represents the ``theme_name`` key that is
used from ``AVAILABLE_THEMES``. To use this setting, the theme must
also be configured inside of ``AVAILABLE_THEMES``.
``THEME_COLLECTION_DIR``
------------------------
.. versionadded:: 9.0.0(Mitaka)
Default: ``"themes"``
This setting tells Horizon which static directory to collect the
available themes into, and therefore which URL points to the theme
collection root. For example, the default theme would be accessible
via ``/{{ STATIC_URL }}/themes/default``.
``THEME_COOKIE_NAME``
---------------------
.. versionadded:: 9.0.0(Mitaka)
Default: ``"theme"``
This setting tells Horizon in which cookie key to store the currently
set theme. The cookie expiration is currently set to a year.
.. _custom_theme_path:
``CUSTOM_THEME_PATH``
---------------------
.. versionadded:: 2015.1(Kilo)
(Deprecated)
Default: ``"themes/default"``
This setting tells Horizon to use a directory as a custom theme.
By default, this directory will serve as the static root of the theme
and the entire contents of the directory will be served up at
``/static/custom``. If you wish to include content other than static
files in a theme directory, but do not wish that content to be served up,
then you can create a sub directory named ``static``. If the theme folder
contains a sub-directory with the name ``static``, then
``static/custom/static`` will be used as the root for the content
served at ``/static/custom``.
The static root of the theme folder must always contain a _variables.scss
file and a _styles.scss file. These must contain or import all the
bootstrap and horizon specific variables and styles which are used to style
the GUI. For example themes, see: /horizon/openstack_dashboard/themes/
Horizon ships with one alternate theme based on Google's Material Design. To
use the alternate theme, set your CUSTOM_THEME_PATH to ``themes/material``.
This option is now marked as "deprecated" and will be removed in Newton or
a later release. Themes are now controlled by AVAILABLE_THEMES. We suggest
changing your custom theme settings to use this option instead.
``DEFAULT_THEME_PATH``
----------------------
.. versionadded:: 8.0.0(Liberty)
(Deprecated)
Default: ``"themes/default"``
This setting allows Horizon to collect an additional theme during static
collection and be served up via /static/themes/default. This is useful
if CUSTOM_THEME_PATH inherits from another theme (like 'default').
If DEFAULT_THEME_PATH is the same as CUSTOM_THEME_PATH, then collection
is skipped and /static/themes will not exist.
This option is now marked as "deprecated" and will be removed in Newton or
a later release. Themes are now controlled by AVAILABLE_THEMES.
``DROPDOWN_MAX_ITEMS``
----------------------
.. versionadded:: 2015.1(Kilo)
Default: ``30``
This setting sets the maximum number of items displayed in a dropdown.
Dropdowns that limit based on this value need to support a way to observe
the entire list.
``ENABLE_CLIENT_TOKEN``
--------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``True``
This setting will Enable/Disable access to the Keystone Token to the
browser.
``ENFORCE_PASSWORD_CHECK``
--------------------------
.. versionadded:: 2015.1(Kilo)
Default: ``False``
This setting will display an 'Admin Password' field on the Change Password
form to verify that it is indeed the admin logged-in who wants to change
the password.
``IMAGES_LIST_FILTER_TENANTS``
------------------------------
.. versionadded:: 2013.1(Grizzly)
Default: ``None``
A list of dictionaries to add optional categories to the image fixed filters
in the Images panel, based on project ownership.
Each dictionary should contain a `tenant` attribute with the project
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': 'icon-ok'}]``
.. note::
Since the Kilo release, the Bootstrap icon library (e.g. 'icon-ok') has
been replaced with Font Awesome (e.g. 'fa-check').
``IMAGE_RESERVED_CUSTOM_PROPERTIES``
------------------------------------
.. versionadded:: 2014.2(Juno)
Default: ``[]``
A list of image custom property keys that should not be displayed in the
Update Metadata tree.
This setting can be used in the case where a separate panel is used for
managing a custom property or if a certain custom property should never be
edited.
``LAUNCH_INSTANCE_DEFAULTS``
----------------------------
.. versionadded:: 9.0.0(Mitaka)
.. versionchanged:: 10.0.0(Newton)
Default::
{
"config_drive": False,
"enable_scheduler_hints": True,
"disable_image": False,
"disable_instance_snapshot": False,
"disable_volume": False,
"disable_volume_snapshot": False,
"create_volume": True,
}
A dictionary of settings which can be used to provide the default values for
properties found in the Launch Instance modal.
The ``config_drive`` setting specifies the default value for the Configuration
Drive property.
The ``enable_scheduler_hints`` setting specifies whether or not Scheduler Hints
can be provided when launching an instance.
The ``create_volume`` setting allows you to specify the default value for the
option of creating a new volume in the workflow for image and instance snapshot
sources.
The ``disable_image`` setting disables Images as a valid boot source for launching
instances. Image sources won't show up in the Launch Instance modal.
The ``disable_instance_snapshot`` setting disables Snapshots as a valid boot
source for launching instances. Snapshots sources won't show up in the Launch
Instance modal.
The ``disable_volume`` setting disables Volumes as a valid boot
source for launching instances. Volumes sources won't show up
in the Launch Instance modal.
The ``disable_volume_snapshot`` setting disables Volume Snapshots as a valid
boot source for launching instances. Volume Snapshots sources won't show up
in the Launch Instance modal.
``LAUNCH_INSTANCE_NG_ENABLED``
------------------------------
.. versionadded:: 8.0.0(Liberty)
Default: ``True``
This setting enables the AngularJS Launch Instance workflow.
.. note::
The default value for this has been changed to ``True`` in 9.0.0 (Mitaka)
.. note::
It is possible to run both the AngularJS and Python workflows simultaneously,
so the other may be need to be toggled with ``LAUNCH_INSTANCE_LEGACY_ENABLED``
``LAUNCH_INSTANCE_LEGACY_ENABLED``
----------------------------------
.. versionadded:: 8.0.0(Liberty)
Default: ``False``
This setting enables the Python Launch Instance workflow.
.. note::
The default value for this has been changed to ``False`` in 9.0.0 (Mitaka)
.. note::
It is possible to run both the AngularJS and Python workflows simultaneously,
so the other may be need to be toggled with ``LAUNCH_INSTANCE_NG_ENABLED``
``MESSAGES_PATH``
-----------------
.. versionadded:: 9.0.0(Mitaka)
Default: ``None``
The absolute path to the directory where message files are collected.
When the user logins to horizon, the message files collected are processed
and displayed to the user. Each message file should contain a JSON formatted
data and must have a .json file extension. For example::
{
"level": "info",
"message": "message of the day here"
}
Possible values for level are: success, info, warning and error.
``OPENSTACK_API_VERSIONS``
--------------------------
.. versionadded:: 2013.2(Havana)
Default::
{
"data-processing": 1.1,
"identity": 2.0,
"volume": 2,
"compute": 2
}
Overrides for OpenStack API versions. Use this setting to force the
OpenStack dashboard to use a specific API version for a given service API.
.. note::
The version should be formatted as it appears in the URL for the
service API. For example, the identity service APIs have inconsistent
use of the decimal point, so valid options would be "2.0" or "3".
For example::
OPENSTACK_API_VERSIONS = {
"data-processing": 1.1,
"identity": 3,
"volume": 2,
"compute": 2
}
``OPENSTACK_ENABLE_PASSWORD_RETRIEVE``
--------------------------------------
.. versionadded:: 2014.1(Icehouse)
Default: ``"False"``
When set, enables the instance action "Retrieve password" allowing password retrieval
from metadata service.
``OPENSTACK_ENDPOINT_TYPE``
---------------------------
.. versionadded:: 2012.1(Essex)
Default: ``"publicURL"``
A string which specifies the endpoint type to use for the endpoints in the
Keystone service catalog. The default value for all services except for identity is ``"publicURL"`` . The default value for the identity service is ``"internalURL"``.
``OPENSTACK_HOST``
------------------
.. versionadded:: 2012.1(Essex)
Default: ``"127.0.0.1"``
The hostname of the Keystone server used for authentication if you only have
one region. This is often the *only* setting that needs to be set for a
basic deployment.
.. _hypervisor-settings-label:
``OPENSTACK_HYPERVISOR_FEATURES``
---------------------------------
.. versionadded:: 2012.2(Folsom)
Default::
{
'can_set_mount_point': False,
'can_set_password': False,
'requires_keypair': False,
'enable_quotas': True
}
A dictionary containing settings which can be used to identify the
capabilities of the hypervisor for Nova.
The Xen Hypervisor has the ability to set the mount point for volumes attached
to instances (other Hypervisors currently do not). Setting
``can_set_mount_point`` to ``True`` will add the option to set the mount point
from the UI.
Setting ``can_set_password`` to ``True`` will enable the option to set
an administrator password when launching or rebuilding an instance.
Setting ``requires_keypair`` to ``True`` will require users to select
a key pair when launching an instance.
Setting ``enable_quotas`` to ``False`` will make Horizon treat all Nova
quotas as disabled, thus it won't try to modify them. By default, quotas are
enabled.
``OPENSTACK_IMAGE_BACKEND``
---------------------------
.. versionadded:: 2013.2(Havana)
Default::
{
'image_formats': [
('', _('Select format')),
('aki', _('AKI - Amazon Kernel Image')),
('ami', _('AMI - Amazon Machine Image')),
('ari', _('ARI - Amazon Ramdisk Image')),
('docker', _('Docker')),
('iso', _('ISO - Optical Disk Image')),
('qcow2', _('QCOW2 - QEMU Emulator')),
('raw', _('Raw')),
('vdi', _('VDI')),
('vhd', _('VHD')),
('vmdk', _('VMDK'))
]
}
Used to customize features related to the image service, such as the list of
supported image formats.
``OVERVIEW_DAYS_RANGE``
-----------------------
.. versionadded:: 10.0.0(Newton)
Default:: ``1``
When set to an integer N (as by default), the start date in the Overview panel
meters will be today minus N days. This setting is used to limit the amount of
data fetched by default when rendering the Overview panel. If set to ``None``
(which corresponds to the behavior in past Horizon versions), the start date
will be from the beginning of the current month until the current date. The
legacy behaviour is not recommended for large deployments as Horizon suffers
significant lags in this case.
``IMAGE_CUSTOM_PROPERTY_TITLES``
--------------------------------
.. versionadded:: 2014.1(Icehouse)
Default::
{
"architecture": _("Architecture"),
"kernel_id": _("Kernel ID"),
"ramdisk_id": _("Ramdisk ID"),
"image_state": _("Euca2ools state"),
"project_id": _("Project ID"),
"image_type": _("Image Type")
}
Used to customize the titles for image custom property attributes that
appear on image detail pages.
``HORIZON_IMAGES_ALLOW_UPLOAD``
-------------------------------
.. versionadded:: 2013.1(Grizzly)
Default: ``True``
(Deprecated)
If set to ``False``, this setting disables *local* uploads to prevent filling
up the disk on the dashboard server since uploads to the Glance image store
service tend to be particularly large - in the order of hundreds of megabytes
to multiple gigabytes.
The setting is marked as deprecated and will be removed in P or later release.
It is superseded by the setting HORIZON_IMAGES_UPLOAD_MODE. Until the removal
the ``False`` value of HORIZON_IMAGES_ALLOW_UPLOAD overrides the value of
HORIZON_IMAGES_UPLOAD_MODE.
.. note::
This will not disable image creation altogether, as this setting does not
affect images created by specifying an image location (URL) as the image source.
``HORIZON_IMAGES_UPLOAD_MODE``
------------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``"legacy"``
Valid values are ``"direct"``, ``"legacy"`` (default) and ``"off"``. ``"off"``
disables the ability to upload images via Horizon. It is equivalent to setting
``False`` on the deprecated setting ``HORIZON_IMAGES_ALLOW_UPLOAD``. ``legacy``
enables local file upload by piping the image file through the Horizon's
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.
.. _here: http://docs.openstack.org/developer/oslo.middleware/cors.html#configuration-for-oslo-config
.. note::
To maintain the compatibility with the deprecated HORIZON_IMAGES_ALLOW_UPLOAD
setting, neither ``"direct"``, nor ``"legacy"`` modes will have an effect if
HORIZON_IMAGES_ALLOW_UPLOAD is set to ``False`` - as if HORIZON_IMAGES_UPLOAD_MODE
was set to ``"off"`` itself. When HORIZON_IMAGES_ALLOW_UPLOAD is set to ``True``,
all three modes are considered, as if HORIZON_IMAGES_ALLOW_UPLOAD setting
was removed.
``IMAGES_ALLOW_LOCATION``
--------------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``False``
If set to ``True``, this setting allows users to specify an image location
(URL) as the image source when creating or updating images. Depending on
the Glance version, the ability to set an image location is controlled by
policies and/or the Glance configuration. Therefore IMAGES_ALLOW_LOCATION
should only be set to ``True`` if Glance is configured to allow specifying a
location. This setting has no effect when the Keystone catalog doesn't contain
a Glance v2 endpoint.
``OPENSTACK_KEYSTONE_BACKEND``
------------------------------
.. versionadded:: 2012.1(Essex)
Default: ``{'name': 'native', 'can_edit_user': True, 'can_edit_project': True}``
A dictionary containing settings which can be used to identify the
capabilities of the auth backend for Keystone.
If Keystone has been configured to use LDAP as the auth backend then set
``can_edit_user`` and ``can_edit_project`` to ``False`` and name to ``"ldap"``.
``OPENSTACK_KEYSTONE_DEFAULT_DOMAIN``
-------------------------------------
.. versionadded:: 2013.2(Havana)
Default: ``"Default"``
Overrides the default domain used when running on single-domain model
with Keystone V3. All entities will be created in the default domain.
``OPENSTACK_KEYSTONE_DEFAULT_ROLE``
-----------------------------------
.. versionadded:: 2011.3(Diablo)
Default: ``"_member_"``
The name of the role which will be assigned to a user when added to a project.
This value must correspond to an existing role name in Keystone. In general,
the value should match the ``member_role_name`` defined in ``keystone.conf``.
``OPENSTACK_KEYSTONE_ADMIN_ROLES``
----------------------------------
.. versionadded:: 2015.1(Kilo)
Default: ``["admin"]``
The list of roles that have administrator privileges in this OpenStack
installation. This check is very basic and essentially only works with
keystone v2.0 and v3 with the default policy file. The setting assumes there
is a common ``admin`` like role(s) across services. Example uses of this
setting are:
* to rename the ``admin`` role to ``cloud-admin``
* allowing multiple roles to have administrative privileges, like
``["admin", "cloud-admin", "net-op"]``
``OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT``
------------------------------------------
.. versionadded:: 2013.2(Havana)
Default: ``False``
Set this to True if running on multi-domain model. When this is enabled, it
will require user to enter the Domain name in addition to username for login.
``OPENSTACK_KEYSTONE_URL``
--------------------------
.. versionadded:: 2011.3(Diablo)
Default: ``"http://%s:5000/v2.0" % OPENSTACK_HOST``
The full URL for the Keystone endpoint used for authentication. Unless you
are using HTTPS, running your Keystone server on a nonstandard port, or using
a nonstandard URL scheme you shouldn't need to touch this setting.
``OPENSTACK_KEYSTONE_FEDERATION_MANAGEMENT``
--------------------------------------------
.. versionadded:: 9.0.0(Mitaka)
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.
``WEBSSO_ENABLED``
------------------
.. versionadded:: 2015.1(Kilo)
Default: ``False``
Enables keystone web single-sign-on if set to True. For this feature to work,
make sure that you are using Keystone V3 and Django OpenStack Auth V1.2.0 or
later.
``WEBSSO_INITIAL_CHOICE``
-------------------------
.. versionadded:: 2015.1(Kilo)
Default: ``"credentials"``
Determines the default authentication mechanism. When user lands on the login
page, this is the first choice they will see.
``WEBSSO_CHOICES``
------------------
.. versionadded:: 2015.1(Kilo)
Default::
(
("credentials", _("Keystone Credentials")),
("oidc", _("OpenID Connect")),
("saml2", _("Security Assertion Markup Language"))
)
This is the list of authentication mechanisms available to the user. It
includes Keystone federation protocols such as OpenID Connect and SAML, and
also keys that map to specific identity provider and federation protocol
combinations (as defined in ``WEBSSO_IDP_MAPPING``). The list of choices is
completely configurable, so as long as the id remains intact. Do not remove
the credentials mechanism unless you are sure. Once removed, even admins will
have no way to log into the system via the dashboard.
``WEBSSO_IDP_MAPPING``
----------------------
.. versionadded:: 8.0.0(Liberty)
Default: ``{}``
A dictionary of specific identity provider and federation protocol combinations.
From the selected authentication mechanism, the value will be looked up as keys
in the dictionary. If a match is found, it will redirect the user to a identity
provider and federation protocol specific WebSSO endpoint in keystone, otherwise
it will use the value as the protocol_id when redirecting to the WebSSO by
protocol endpoint.
Example::
WEBSSO_CHOICES = (
("credentials", _("Keystone Credentials")),
("oidc", _("OpenID Connect")),
("saml2", _("Security Assertion Markup Language")),
("acme_oidc", "ACME - OpenID Connect"),
("acme_saml2", "ACME - SAML2")
)
WEBSSO_IDP_MAPPING = {
"acme_oidc": ("acme", "oidc"),
"acme_saml2": ("acme", "saml2")
}
.. note::
The value is expected to be a tuple formatted as: (<idp_id>, <protocol_id>).
``TOKEN_DELETE_DISABLED``
-------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``False``
This setting allows deployers to control whether a token is deleted on log out.
This can be helpful when there are often long running processes being run
in the Horizon environment.
``OPENSTACK_CINDER_FEATURES``
-----------------------------
.. versionadded:: 2014.2(Juno)
Default: ``{'enable_backup': False}``
A dictionary of settings which can be used to enable optional services provided
by cinder. Currently only the backup service is available.
``OPENSTACK_HEAT_STACK``
-----------------------------
.. versionadded:: 9.0.0(Mitaka)
Default: ``{'enable_user_pass': True}``
A dictionary of settings to use with heat stacks. Currently, the only setting
available is "enable_user_pass", which can be used to disable the password
field while launching the stack. Currently HEAT API needs user password to
perform all the heat operations because in HEAT API trusts is not enabled by
default. So, this setting can be set as "False" in-case HEAT uses trusts by
default otherwise it needs to be set as "True".
``OPENSTACK_NEUTRON_NETWORK``
-----------------------------
.. versionadded:: 2013.1(Grizzly)
Default::
{
'enable_router': True,
'enable_distributed_router': False,
'enable_ha_router': False,
'enable_quotas': False,
'enable_firewall': True,
'enable_vpn': True,
'profile_support': None,
'supported_vnic_types': ["*"],
'supported_provider_types': ["*"],
'segmentation_id_range': {},
'extra_provider_types': {},
'enable_fip_topology_check': True,
'enable_ipv6': True,
'enable_lb', True,
'default_dns_nameservers': [],
}
A dictionary of settings which can be used to enable optional services provided
by Neutron and configure Neutron specific features. The following options are
available.
``enable_router``
~~~~~~~~~~~~~~~~~
.. versionadded:: 2014.2(Juno)
Default: ``True``
Enable (True) or disable (False) the panels and menus related
to router and Floating IP features. This option only affects
when Neutron is enabled. If your Neutron deployment has no support for
Layer-3 features, or you do not wish to provide the Layer-3
features through the Dashboard, this should be set to ``False``.
``enable_distributed_router``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 2014.2(Juno)
Default: ``False``
Enable or disable Neutron distributed virtual router (DVR) feature in
the Router panel. For the DVR feature to be enabled, this option needs
to be set to True and your Neutron deployment must support DVR. Even
when your Neutron plugin (like ML2 plugin) supports DVR feature, DVR
feature depends on l3-agent configuration, so deployers should set this
option appropriately depending on your deployment.
``enable_ha_router``
~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 2014.2(Juno)
Default: ``False``
Enable or disable HA (High Availability) mode in Neutron virtual router
in the Router panel. For the HA router mode to be enabled, this option needs
to be set to True and your Neutron deployment must support HA router mode.
Even when your Neutron plugin (like ML2 plugin) supports HA router mode,
the feature depends on l3-agent configuration, so deployers should set this
option appropriately depending on your deployment.
``enable_quotas``
~~~~~~~~~~~~~~~~~
Default: ``False``
Enable support for Neutron quotas feature. To make this feature work
appropriately, you need to use Neutron plugins with quotas extension support
and quota_driver should be DbQuotaDriver (default config).
``enable_firewall``
~~~~~~~~~~~~~~~~~~~
(Deprecated)
Default: ``True``
Enables the firewall panel. firewall panel will be enabled when this
option is True and your Neutron deployment supports FWaaS. If you want
to disable firewall panel even when your Neutron supports FWaaS, set
it to False.
This option is now marked as "deprecated" and will be removed in
Kilo or later release. The firewall panel is now enabled only
when FWaaS feature is available in Neutron and this option is no
longer needed. We suggest not to use this option to disable the
firewall panel from now on.
``enable_vpn``
~~~~~~~~~~~~~~
(Deprecated)
Default: ``True``
Enables the VPN panel. VPN panel will be enabled when this option is True
and your Neutron deployment supports VPNaaS. If you want to disable
VPN panel even when your Neutron supports VPNaaS, set it to False.
This option is now marked as "deprecated" and will be removed in
Kilo or later release. The VPN panel is now enabled only
when VPNaaS feature is available in Neutron and this option is no
longer needed. We suggest not to use this option to disable the
VPN panel from now on.
``profile_support``
~~~~~~~~~~~~~~~~~~~
Default: ``None``
This option specifies a type of network port profile support. Currently the
available value is either ``None`` or ``"cisco"``. ``None`` means to disable
port profile support. ``cisco`` can be used with Neutron Cisco plugins.
``supported_provider_types``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 2014.2(Juno)
Default: ``["*"]``
For use with the provider network extension. Use this to explicitly set which
provider network types are supported. Only the network types in this list will
be available to choose from when creating a network.
Network types defined in Horizon or defined in ``extra_provider_types``
settings can be specified in this list.
As of the Newton release, the network types defined in Horizon include
network types supported by Neutron ML2 plugin with Open vSwitch driver
(``local``, ``flat``, ``vlan``, ``gre``, ``vxlan`` and ``geneve``)
and supported by Midonet plugin (``midonet`` and ``uplink``).
``["*"]`` means that all provider network types supported by Neutron
ML2 plugin will be available to choose from.
Example: ``['local', 'flat', 'gre']``
``supported_vnic_types``
~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 2015.1(Kilo)
Default ``['*']``
For use with the port binding extension. Use this to explicitly set which VNIC
types are supported; only those listed will be shown when creating or editing
a port. VNIC types include normal, direct and macvtap. By default all VNIC
types will be available to choose from.
Example ``['normal', 'direct']``
To disable VNIC type selection, set an empty list or None.
``segmentation_id_range``
~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 2014.2(Juno)
Default: ``{}``
For use with the provider network extension. This is a dictionary where each
key is a provider network type and each value is a list containing two numbers.
The first number is the minimum segmentation ID that is valid. The second
number is the maximum segmentation ID. Pertains only to the vlan, gre, and
vxlan network types. By default this option is not provided and each minimum
and maximum value will be the default for the provider network type.
Example::
{
'vlan': [1024, 2048],
'gre': [4094, 65536]
}
``extra_provider_types``
~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 10.0.0(Newton)
Default: ``{}``
For use with the provider network extension.
This is a dictionary to define extra provider network definitions.
Network types supported by Neutron depend on the configured plugin.
Horizon has predefined provider network types but horizon cannot cover
all of them. If you are using a provider network type not defined
in advance, you can add a definition through this setting.
The **key** name of each item in this must be a network type used
in the Neutron API. * **value** should be a dictionary which contains
the following items:
* ``display_name``: string displayed in the network creation form.
* ``require_physical_network``: a boolean parameter which indicates
this network type requires a physical network.
* ``require_segmentation_id``: a boolean parameter which indicates
this network type requires a segmentation ID.
If True, a valid segmentation ID range must be configured
in ``segmentation_id_range`` settings above.
Example::
{
'awesome': {
'display_name': 'Awesome',
'require_physical_network': False,
'require_segmentation_id': True,
},
}
``enable_fip_topology_check``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Default: ``True``
The Default Neutron implementation needs a router with a gateway to associate a
FIP. So by default a topology check will be performed by horizon to list only
VM ports attached to a network which is itself attached to a router with an
external gateway. This is to prevent from setting a FIP to a port which will
fail with an error.
Some Neutron vendors do not require it. Some can even attach a FIP to any port
(e.g.: OpenContrail) owned by a tenant.
Set to False if you want to be able to associate a FIP to an instance on a
subnet with no router if your Neutron backend allows it.
.. versionadded:: 8.0.0(Liberty)
``default_dns_nameservers``:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 10.0.0(Newton)
Default: ``None`` (Empty)
Default DNS servers you would like to use when a subnet is created. This is
only a default. Users can still choose a different list of dns servers.
Example: ``["8.8.8.8", "8.8.4.4", "208.67.222.222"]``
``OPENSTACK_SSL_CACERT``
------------------------
.. versionadded:: 2013.2(Havana)
Default: ``None``
When unset or set to ``None`` the default CA certificate on the system is used
for SSL verification.
When set with the path to a custom CA certificate file, this overrides use of
the default system CA certificate. This custom certificate is used to verify all
connections to openstack services when making API calls.
``OPENSTACK_SSL_NO_VERIFY``
---------------------------
.. versionadded:: 2012.2(Folsom)
Default: ``False``
Disable SSL certificate checks in the OpenStack clients (useful for self-signed
certificates).
``OPENSTACK_TOKEN_HASH_ALGORITHM``
----------------------------------
.. versionadded:: 2014.2(Juno)
Default: ``"md5"``
The hash algorithm to use for authentication tokens. This must match the hash
algorithm that the identity (Keystone) server and the auth_token middleware
are using. Allowed values are the algorithms supported by Python's hashlib
library.
``OPENSTACK_TOKEN_HASH_ENABLED``
--------------------------------
.. versionadded:: 8.0.0(Liberty)
(Deprecated)
Default: ``True``
Hashing tokens from Keystone keeps the Horizon session data smaller, but it
doesn't work in some cases when using PKI tokens. Uncomment this value and
set it to False if using PKI tokens and there are 401 errors due to token
hashing.
This option is now marked as "deprecated" and will be removed in Ocata or a
later release. PKI tokens currently work with hashing, and Keystone will soon
deprecate usage of PKI tokens.
``POLICY_FILES``
----------------
.. versionadded:: 2013.2(Havana)
Default: ``{'identity': 'keystone_policy.json', 'compute': 'nova_policy.json'}``
This should essentially be the mapping of the contents of ``POLICY_FILES_PATH``
to service types. When policy.json files are added to ``POLICY_FILES_PATH``,
they should be included here too.
``POLICY_FILES_PATH``
---------------------
.. versionadded:: 2013.2(Havana)
Default: ``os.path.join(ROOT_PATH, "conf")``
Specifies where service based policy files are located. These are used to
define the policy rules actions are verified against.
``SESSION_TIMEOUT``
-------------------
.. versionadded:: 2013.2(Havana)
Default: ``"3600"``
This SESSION_TIMEOUT is a method to supercede the token timeout with a shorter
horizon session timeout (in seconds). So if your token expires in 60 minutes,
a value of 1800 will log users out after 30 minutes.
``SAHARA_AUTO_IP_ALLOCATION_ENABLED``
-------------------------------------
Default: ``False``
This setting notifies the Data Processing (Sahara) system whether or not
automatic IP allocation is enabled. You would want to set this to True
if you were running Nova Networking with auto_assign_floating_ip = True.
``TROVE_ADD_USER_PERMS`` and ``TROVE_ADD_DATABASE_PERMS``
---------------------------------------------------------
.. versionadded:: 2013.2(Havana)
Default: ``[]``
Trove user and database extension support. By default, support for
creating users and databases on database instances is turned on.
To disable these extensions set the permission to something
unusable such as ``[!]``.
``WEBROOT``
-----------
.. versionadded:: 2015.1(Kilo)
Default: ``"/"``
Specifies the location where the access to the dashboard is configured in
the web server.
For example, if you're accessing the Dashboard via
https://<your server>/dashboard, you would set this to ``"/dashboard/"``.
.. note::
Additional settings may be required in the config files of your webserver
of choice. For example to make ``"/dashboard/"`` the web root in Apache,
the ``"sites-available/horizon.conf"`` requires a couple of additional
aliases set::
Alias /dashboard/static %HORIZON_DIR%/static
Alias /dashboard/media %HORIZON_DIR%/openstack_dashboard/static
Apache also requires changing your WSGIScriptAlias to reflect the desired
path. For example, you'd replace ``/`` with ``/dashboard`` for the
alias.
``STATIC_ROOT``
---------------
.. versionadded:: 8.0.0(Liberty)
Default: ``<path_to_horizon>/static``
The absolute path to the directory where static files are collected when
collectstatic is run.
For more information see:
https://docs.djangoproject.com/en/dev/ref/settings/#static-root
``STATIC_URL``
--------------
.. versionadded:: 8.0.0(Liberty)
Default: ``/static/``
URL that refers to files in STATIC_ROOT.
By default this value is ``WEBROOT/static/``.
This value can be changed from the default. When changed, the alias in your
webserver configuration should be updated to match.
.. note::
The value for STATIC_URL must end in '/'.
This value is also available in the scss namespace with the variable name
$static_url. Make sure you run ``python manage.py collectstatic`` and
``python manage.py compress`` after any changes to this value in settings.py.
For more information see:
https://docs.djangoproject.com/en/dev/ref/settings/#static-url
``DISALLOW_IFRAME_EMBED``
-------------------------
.. versionadded:: 8.0.0(Liberty)
Default: ``True``
This setting can be used to defend against Clickjacking and prevent Horizon from
being embedded within an iframe. Legacy browsers are still vulnerable to a
Cross-Frame Scripting (XFS) vulnerability, so this option allows extra security
hardening where iframes are not used in deployment. When set to true, a
``"frame-buster"`` script is inserted into the template header that prevents the
web page from being framed and therefore defends against clickjacking.
For more information see:
http://tinyurl.com/anticlickjack
.. note::
If your deployment requires the use of iframes, you can set this setting to
``False`` to exclude the frame-busting code and allow iframe embedding.
``OPENSTACK_NOVA_EXTENSIONS_BLACKLIST``
---------------------------------------
.. versionadded:: 8.0.0(Liberty)
Default: ``[]``
Ignore all listed Nova extensions, and behave as if they were unsupported.
Can be used to selectively disable certain costly extensions for performance
reasons.
``OPENSTACK_PROFILER``
----------------------
.. versionadded:: 11.0.0(Ocata)
Default: ``{"enabled": False}``
Various settings related to integration with osprofiler library. Since it is a
developer feature, it starts as disabled. To enable it, more than a single
``"enabled"`` key should be specified. Additional keys that should be specified
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"]``.
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,
because other components act mostly as traces producers. Example:
``"notifier_connection_string": "mongodb://%s' % OPENSTACK_HOST"``.
* ``"receiver_connection_string"`` is a url from which traces are retrieved by
Horizon, needed because Horizon is not only the traces producer, but also a
consumer. Having 2 settings which usually contain the same value is legacy
feature from older versions of osprofiler when OpenStack components could use
oslo.messaging for notifications and the trace client used ceilometer as a
receiver backend. By default Horizon uses the same URL pointing to a MongoDB
cluster for both purposes, since ceilometer was too slow for using with UI.
Example: ``"receiver_connection_string": "mongodb://%s" % OPENSTACK_HOST``.
.. _osprofiler documentation: http://docs.openstack.org/developer/osprofiler/integration.html#how-to-initialize-profiler-to-get-one-trace-across-all-services
``ALLOWED_PRIVATE_SUBNET_CIDR``
-------------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``{'ipv4': [], 'ipv6': []}``
Dict used to restrict user private subnet cidr range.
An empty list means that user input will not be restricted
for a corresponding IP version. By default, there is
no restriction for both IPv4 and IPv6.
Example: ``{'ipv4': ['192.168.0.0/16', '10.0.0.0/8'], 'ipv6': ['fc00::/7',]}``
``FILTER_DATA_FIRST``
---------------------------
.. versionadded:: 10.0.0(Newton)
Default::
{
'admin.instances': False,
'admin.images': False,
'admin.networks': False,
'admin.routers': False,
'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.
Examples:
Override the dict::
{
'admin.instances': True,
'admin.images': True,
'admin.networks': False,
'admin.routers': False,
'admin.volumes': False
}
Or, if you want to turn this on for an specific panel/view do::
FILTER_DATA_FIRST['admin.instances'] = True
``OPERATION_LOG_ENABLED``
-------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``False``
This setting can be used to log operations of all of users on Horizon.
In this log, it can include date and time of an operation, an operation URL,
user information such as domain, project and user, and so on.
And this log format is configurable. In detail, you can see OPERATION_LOG_OPTIONS.
.. note::
If you use this feature, you need to configure the logger setting like
a outputting path for operation log in ``local_settings.py``.
``OPERATION_LOG_OPTIONS``
-------------------------
.. versionadded:: 10.0.0(Newton)
Default::
{
'mask_fields': ['password'],
'target_methods': ['POST'],
'format': ("[%(domain_name)s] [%(domain_id)s] [%(project_name)s]"
" [%(project_id)s] [%(user_name)s] [%(user_id)s] [%(request_scheme)s]"
" [%(referer_url)s] [%(request_url)s] [%(message)s] [%(method)s]"
" [%(http_status)s] [%(param)s]"),
}
This setting controls the behavior of the operation log.
* ``mask_fields`` is a list of keys of post data which should be masked from the
point of view of security. Fields like ``password`` should be included.
The fields specified in ``mask_fields`` are logged as ``********``.
* ``target_methods`` is a request method which is logged to a operation log.
The valid methods are ``POST``, ``GET``, ``PUT``, ``DELETE``.
* ``format`` defines the operation log format.
Currently you can use the following keywords.
The default value contains all keywords.
* %(domain_name)s
* %(domain_id)s
* %(project_name)s
* %(project_id)s
* %(user_name)s
* %(user_id)s
* %(request_scheme)s
* %(referer_url)s
* %(request_url)s
* %(message)s
* %(method)s
* %(http_status)s
* %(param)s
``PROJECT_TABLE_EXTRA_INFO``
----------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``{}``
Add additional information for project as an extra attribute.
Project and user can have any attributes by keystone mechanism.
This setting can treat these attributes on Horizon when only
using Keystone v3.
For example::
PROJECT_TABLE_EXTRA_INFO = {
'phone_num': _('Phone Number'),
}
``USER_TABLE_EXTRA_INFO``
-------------------------
.. versionadded:: 10.0.0(Newton)
Default: ``{}``
Same as ``PROJECT_TABLE_EXTRA_INFO``, add additional information for user.
Django Settings (Partial)
=========================
.. warning::
This is not meant to be anywhere near a complete list of settings for
Django. You should always consult the upstream documentation, especially
with regards to deployment considerations and security best-practices.
There are a few key settings you should be aware of for development and the
most basic of deployments. Further recommendations can be found in the
Deploying Horizon section of this documentation.
``ALLOWED_HOSTS``
-----------------
.. versionadded:: 2013.2(Havana)
Default: ``['localhost']``
This list should contain names (or IP addresses) of the host
running the dashboard; if it's being accessed via name, the
DNS name (and probably short-name) should be added, if it's accessed via
IP address, that should be added. The setting may contain more than one entry.
.. note::
ALLOWED_HOSTS is required. If Horizon is running in production (DEBUG is False),
set this with the list of host/domain names that the application can serve.
For more information see:
https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts
.. _debug_setting:
``DEBUG`` and ``TEMPLATE_DEBUG``
--------------------------------
.. versionadded:: 2011.2(Cactus)
Default: ``True``
Controls whether unhandled exceptions should generate a generic 500 response
or present the user with a pretty-formatted debug information page.
When set, CACHED_TEMPLATE_LOADERS will not be cached.
This setting should **always** be set to ``False`` for production deployments
as the debug page can display sensitive information to users and attackers
alike.
``TEMPLATE_LOADERS``
--------------------
.. versionadded:: 10.0.0(Newton)
These template loaders will be the first loaders and get loaded before the
CACHED_TEMPLATE_LOADERS. Use ADD_TEMPLATE_LOADERS if you want to add loaders at
the end and not cache loaded templates.
After the whole settings process has gone through, TEMPLATE_LOADERS will be::
TEMPLATE_LOADERS += (
('django.template.loaders.cached.Loader', CACHED_TEMPLATE_LOADERS),
) + tuple(ADD_TEMPLATE_LOADERS)
``CACHED_TEMPLATE_LOADERS``
---------------------------
.. versionadded:: 10.0.0(Newton)
Template loaders defined here will have their output cached if DEBUG
is set to False.
``ADD_TEMPLATE_LOADERS``
------------------------
.. versionadded:: 10.0.0(Newton)
Template loaders defined here will be loaded at the end of TEMPLATE_LOADERS,
after the CACHED_TEMPLATE_LOADERS and will never have a cached output.
``NG_TEMPLATE_CACHE_AGE``
-------------------------
.. versionadded:: 10.0.0(Newton)
Angular Templates are cached using this duration (in seconds) if DEBUG
is set to False. Default value is ``2592000`` (or 30 days).
``SECRET_KEY``
--------------
.. versionadded:: 2012.1(Essex)
This should absolutely be set to a unique (and secret) value for your
deployment. Unless you are running a load-balancer with multiple Horizon
installations behind it, each Horizon instance should have a unique secret key.
.. note::
Setting a custom secret key:
You can either set it to a specific value or you can let Horizon generate a
default secret key that is unique on this machine, regardless of the
amount of Python WSGI workers (if used behind Apache+mod_wsgi). However, there
may be situations where you would want to set this explicitly, e.g. when
multiple dashboard instances are distributed on different machines (usually
behind a load-balancer). Either you have to make sure that a session gets all
requests routed to the same dashboard instance or you set the same SECRET_KEY
for all of them.
From horizon.utils import secret_key::
SECRET_KEY = secret_key.generate_or_read_from_file(
os.path.join(LOCAL_PATH, '.secret_key_store'))
The ``local_settings.py.example`` file includes a quick-and-easy way to
generate a secret key for a single installation.
``SECURE_PROXY_SSL_HEADER``, ``CSRF_COOKIE_SECURE`` and ``SESSION_COOKIE_SECURE``
---------------------------------------------------------------------------------
.. versionadded:: 2013.1(Grizzly)
These three settings should be configured if you are deploying Horizon with
SSL. The values indicated in the default ``local_settings.py.example`` file
are generally safe to use.
When CSRF_COOKIE_SECURE or SESSION_COOKIE_SECURE are set to True, these attributes
help protect the session cookies from cross-site scripting.
``ADD_INSTALLED_APPS``
----------------------
.. versionadded:: 2015.1(Kilo)
A list of Django applications to be prepended to the ``INSTALLED_APPS``
setting. Allows extending the list of installed applications without having
to override it completely.
.. _pluggable-settings-label:
Pluggable Settings
==================
Horizon allows dashboards, panels and panel groups to be added without
modifying the default settings. Pluggable settings are a mechanism to allow
settings to be stored in separate files. Those files are read at startup and
used to modify the default settings.
The default location for the dashboard configuration files is
``openstack_dashboard/enabled``, with another directory,
``openstack_dashboard/local/enabled`` for local overrides. Both sets of files
will be loaded, but the settings in ``openstack_dashboard/local/enabled`` will
overwrite the default ones. The settings are applied in alphabetical order of
the filenames. If the same dashboard has configuration files in ``enabled`` and
``local/enabled``, the local name will be used. Note, that since names of
python modules can't start with a digit, the files are usually named with a
leading underscore and a number, so that you can control their order easily.
Before we describe the specific use cases, the following keys can be used in
any pluggable settings file:
``ADD_EXCEPTIONS``
------------------
.. versionadded:: 2014.1(Icehouse)
A dictionary of exception classes to be added to ``HORIZON['exceptions']``.
``ADD_INSTALLED_APPS``
----------------------
.. versionadded:: 2014.1(Icehouse)
A list of applications to be prepended to ``INSTALLED_APPS``.
This is needed to expose static files from a plugin.
``ADD_ANGULAR_MODULES``
-----------------------
.. versionadded:: 2014.2(Juno)
A list of AngularJS modules to be loaded when Angular bootstraps. These modules
are added as dependencies on the root Horizon application ``horizon``.
``ADD_JS_FILES``
----------------
.. 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.
``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.
``ADD_SCSS_FILES``
------------------
.. versionadded:: 8.0.0(Liberty)
A list of scss files to be included in the compressed set of files that are
loaded on every page. We recommend one scss file per dashboard, use @import if
you need to include additional scss files for panels.
.. _auto_discover_static_files:
``AUTO_DISCOVER_STATIC_FILES``
------------------------------
.. 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.
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`.
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``
------------
.. versionadded:: 2014.1(Icehouse)
If set to ``True``, this settings file will not be added to the settings.
``UPDATE_HORIZON_CONFIG``
-------------------------
.. versionadded:: 2014.2(Juno)
A dictionary of values that will replace the values in ``HORIZON_CONFIG``.
Pluggable Settings for Dashboards
=================================
.. versionadded:: 2014.1(Icehouse)
The following keys are specific to registering a dashboard:
``DASHBOARD``
-------------
.. versionadded:: 2014.1(Icehouse)
The slug of the dashboard to be added to ``HORIZON['dashboards']``. Required.
``DEFAULT``
-----------
.. versionadded:: 2014.1(Icehouse)
If set to ``True``, this dashboard will be set as the default dashboard.
Examples
--------
To disable a dashboard locally, create a file
``openstack_dashboard/local/enabled/_40_dashboard-name.py`` with the following
content::
DASHBOARD = '<dashboard-name>'
DISABLED = True
To add a Tuskar-UI (Infrastructure) dashboard, you have to install it, and then
create a file ``openstack_dashboard/local/enabled/_50_tuskar.py`` with::
from tuskar_ui import exceptions
DASHBOARD = 'infrastructure'
ADD_INSTALLED_APPS = [
'tuskar_ui.infrastructure',
]
ADD_EXCEPTIONS = {
'recoverable': exceptions.RECOVERABLE,
'not_found': exceptions.NOT_FOUND,
'unauthorized': exceptions.UNAUTHORIZED,
}
Pluggable Settings for Panels
=============================
.. versionadded:: 2014.1(Icehouse)
The following keys are specific to registering or removing a panel:
``PANEL``
---------
.. versionadded:: 2014.1(Icehouse)
The slug of the panel to be added to ``HORIZON_CONFIG``. Required.
``PANEL_DASHBOARD``
-------------------
.. versionadded:: 2014.1(Icehouse)
The slug of the dashboard the ``PANEL`` associated with. Required.
``PANEL_GROUP``
---------------
.. versionadded:: 2014.1(Icehouse)
The slug of the panel group the ``PANEL`` is associated with. If you want the
panel to show up without a panel group, use the panel group "default".
``DEFAULT_PANEL``
-----------------
.. versionadded:: 2014.1(Icehouse)
If set, it will update the default panel of the ``PANEL_DASHBOARD``.
``ADD_PANEL``
-------------
.. versionadded:: 2014.1(Icehouse)
Python panel class of the ``PANEL`` to be added.
``REMOVE_PANEL``
----------------
.. versionadded:: 2014.1(Icehouse)
If set to ``True``, the PANEL will be removed from PANEL_DASHBOARD/PANEL_GROUP.
Examples
--------
To add a new panel to the Admin panel group in Admin dashboard, create a file
``openstack_dashboard/local/enabled/_60_admin_add_panel.py`` with the following
content::
PANEL = 'plugin_panel'
PANEL_DASHBOARD = 'admin'
PANEL_GROUP = 'admin'
ADD_PANEL = 'test_panels.plugin_panel.panel.PluginPanel'
To remove Info panel from Admin panel group in Admin dashboard locally, create
a file ``openstack_dashboard/local/enabled/_70_admin_remove_panel.py`` with
the following content::
PANEL = 'info'
PANEL_DASHBOARD = 'admin'
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
following content::
PANEL = 'instances'
PANEL_DASHBOARD = 'admin'
PANEL_GROUP = 'admin'
DEFAULT_PANEL = 'instances'
Pluggable Settings for Panel Groups
===================================
.. versionadded:: 2014.1(Icehouse)
The following keys are specific to registering a panel group:
``PANEL_GROUP``
---------------
.. versionadded:: 2014.1(Icehouse)
The slug of the panel group to be added to ``HORIZON_CONFIG``. Required.
``PANEL_GROUP_NAME``
--------------------
.. versionadded:: 2014.1(Icehouse)
The display name of the PANEL_GROUP. Required.
``PANEL_GROUP_DASHBOARD``
-------------------------
.. versionadded:: 2014.1(Icehouse)
The slug of the dashboard the ``PANEL_GROUP`` associated with. Required.
Examples
--------
To add a new panel group to the Admin dashboard, create a file
``openstack_dashboard/local/enabled/_90_admin_add_panel_group.py`` with the
following content::
PANEL_GROUP = 'plugin_panel_group'
PANEL_GROUP_NAME = 'Plugin Panel Group'
PANEL_GROUP_DASHBOARD = 'admin'
View Git Blame Copy Permalink