==================================
Horizon 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``
--------------

Default: ``None``

Horizon Dashboards are automatically discovered in the following way:

* By traversing Django's list of
  `INSTALLED_APPS <https://docs.djangoproject.com/en/1.4/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.
* By adding a configuration file to the ``openstack_dashboard/local/enabled``
  directory (for more information see :ref:`pluggable-settings-label`).

By default, these dashboards are ordered alphabetically.
However, 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 alphabetical order.

The dashboards listed must be in a Python module which
is included in the ``INSTALLED_APPS`` list and on the Python path.

``default_dashboard``
---------------------

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

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

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

Default: ``2500``

How frequently resources in transition states should be polled for updates,
expressed in milliseconds.

``help_url``
------------

Default: ``None``

If provided, a "Help" link will be displayed in the site header which links
to the value of this settings (ideally a URL containing help information).

``exceptions``
--------------

Default: ``{'unauthorized': [], 'not_found': [], 'recoverable': []}``

A dictionary containing classes of exceptions which Horizon's centralized
exception handling should be aware of.

``password_validator``
----------------------

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

Default: ``"on"``

Controls whether browser autocompletion should be enabled on the login form.
Valid values are ``"on"`` and ``"off"``.

``simple_ip_management``
------------------------

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.

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

``API_RESULT_LIMIT``
--------------------

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

Default: ``20``

Similar to ``API_RESULT_LIMIT``. This setting currently only controls the
Glance image list page size. It will be removed in a future version.


``AVAILABLE_REGIONS``
---------------------

Default: ``None``

A tuple 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.

If you do not have multiple regions you should use the ``OPENSTACK_HOST`` and
``OPENSTACK_KEYSTONE_URL`` settings instead.

``CREATE_INSTANCE_FLAVOR_SORT``
-------------------

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,
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,
    }

``IMAGES_LIST_FILTER_TENANTS``
------------------------------

Default: ``None``

A list of dictionaries to add optional categories to the image filters
in the Images & Snapshots 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'}]``

``OPENSTACK_ENABLE_PASSWORD_RETRIEVE``
---------------------------

Default: ``"False"``

When set, enables the instance action "Retrieve password" allowing password retrieval
from metadata service.


``OPENSTACK_ENDPOINT_TYPE``
---------------------------

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

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.


``OPENSTACK_HYPERVISOR_FEATURES``
---------------------------------

Default::

    {
        'can_set_mount_point': False,
        'can_set_password': False
    }

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.


``OPENSTACK_IMAGE_BACKEND``
---------------------------

Default::

    {
        'image_formats': [
            ('', ''),
            ('aki', _('AKI - Amazon Kernel Image')),
            ('ami', _('AMI - Amazon Machine Image')),
            ('ari', _('ARI - Amazon Ramdisk Image')),
            ('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.


``OPENSTACK_KEYSTONE_BACKEND``
------------------------------

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_ROLE``
-----------------------------------

Default: ``"_member_"``

The name of the role which will be assigned to a user when added to a project.
This name must correspond to a role name in Keystone.


``OPENSTACK_KEYSTONE_URL``
--------------------------

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_NEUTRON_NETWORK``
-----------------------------

Default: ``{'enable_lb': False}``

A dictionary of settings which can be used to enable optional services provided
by neutron.  Currently only the load balancer service is available.


``OPENSTACK_SSL_CACERT``
------------------------

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

Default: ``False``

Disable SSL certificate checks in the OpenStack clients (useful for self-signed
certificates).


``POLICY_FILES``
----------------

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

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

Default: ``"1800"``

Specifies the timespan in seconds inactivity, until a user is considered as
 logged out.

``FLAVOR_EXTRA_KEYS``
---------------------------

Default::

    {
        'flavor_keys': [
            ('quota:read_bytes_sec', _('Quota: Read bytes')),
            ('quota:write_bytes_sec', _('Quota: Write bytes')),
            ('quota:cpu_quota', _('Quota: CPU')),
            ('quota:cpu_period', _('Quota: CPU period')),
            ('quota:inbound_average', _('Quota: Inbound average')),
            ('quota:outbound_average', _('Quota: Outbound average'))
        ]
    }

Used to customize flavor extra specs keys


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

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.



``DEBUG`` and ``TEMPLATE_DEBUG``
--------------------------------

Default: ``True``

Controls whether unhandled exceptions should generate a generic 500 response
or present the user with a pretty-formatted debug information page.

This setting should **always** be set to ``False`` for production deployments
as the debug page can display sensitive information to users and attackers
alike.

``SECRET_KEY``
--------------

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.

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

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.

.. _pluggable-settings-label:

Pluggable Settings for Dashboards
=================================

Many dashboards may require their own modifications to the settings, and their
installation would therefore require modifying the settings file. This is not
optimal, so the dashboards can provide the settings that they require in a
separate file. 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.

The files contain following keys:

``DASHBOARD``
-------------

The name of the dashboard to be added to ``HORIZON['dashboards']``. Required.

``DEFAULT``
-----------

If set to ``True``, this dashboard will be set as the default dashboard.

``ADD_EXCEPTIONS``
------------------

A dictionary of exception classes to be added to ``HORIZON['exceptions']``.

``ADD_INSTALLED_APPS``
----------------------

A list of applications to be prepended to ``INSTALLED_APPS``.

``DISABLED``
------------

If set to ``True``, this dashboard will not be added to the settings.

Examples
--------

To disable the Router dashboard locally, create a file
``openstack_dashboard/local/enabled/_40_router.py`` with the following
content::

    DASHBOARD = 'router'
    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
=============================

Panels customization can be made by providing a custom python module that
contains python code to add or remove panel to/from the dashboard. This
requires altering the settings file. For panels provided by third-party,
making this changes to add the panel is challenging. Panel configuration
files can now be dropped to a specified location and it will be read at startup
to alter the dashboard configuration.

The default location for the panel 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 panel 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.

The files contain following keys:

``PANEL``
-------------

The name of the panel to be added to ``HORIZON_CONFIG``. Required.

``PANEL_DASHBOARD``
-------------

The name of the dashboard the ``PANEL`` associated with. Required.


``PANEL_GROUP``
-------------

The name of the panel group the ``PANEL`` is associated with.

``DEFAULT_PANEL``
-----------

If set, it will update the default panel of the ``PANEL_DASHBOARD``.

``ADD_PANEL``
----------------------

Python panel class of the ``PANEL`` to be added.

``REMOVE_PANEL``
------------

If set to ``True``, the PANEL will be removed from PANEL_DASHBOARD/PANEL_GROUP.

``DISABLED``
------------

If set to ``True``, this panel configuration will be skipped.

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

To organize the panels created from the pluggable settings, there is also
a way to create panel group though configuration file. This creates an empty
panel group to act as placeholder for the panels that can be created later.

The default location for the panel group 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 panel 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.

When writing configuration files to create panels and panels group, make sure
that the panel group configuration file is loaded first because the panel
configuration might be referencing it. This can be achieved by providing a file
name that will go before the panel configuration file when the files are sorted
alphabetically.

The files contain following keys:

``PANEL_GROUP``
-------------

The name of the panel group to be added to ``HORIZON_CONFIG``. Required.

``PANEL_GROUP_NAME``
-------------

The display name of the PANEL_GROUP. Required.

``PANEL_GROUP_DASHBOARD``
-------------

The name of the dashboard the ``PANEL_GROUP`` associated with. Required.

``DISABLED``
------------

If set to ``True``, this panel configuration will be skipped.

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'
