Updates to horizon settings.rst

Added documentation for auto_fade_alerts.

Also added to the OpenStack section documentation for:
OPENSTACK_API_VERSIONS,
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT,
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN,
OPENSTACK_KEYSTONE_BACKEND,
CONSOLE_TYPE,
TROVE_ADD_USER_PERMS,
TROVE_ADD_DATABASE_PERMS.

In the Django section, added ALLOWED_HOSTS
and a note about use of SECRET_KEY.

Closes-Bug: #1221115
Change-Id:  I16596fef2af62b892cef00ab25e2bfe4a80e1c65
This commit is contained in:
Denise Hale 2014-08-28 16:54:50 -07:00 committed by Akihiro Motoki
parent f0d8f1a729
commit 8c3e36e6ce
1 changed files with 159 additions and 48 deletions

207
doc/source/topics/settings.rst Normal file → Executable file
View File

@ -136,6 +136,17 @@ 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-success', 'alert-info', 'alert-warning', 'alert-error']
Can also define the delay before the alert fades and the fade out duration.
``help_url``
------------
@ -257,6 +268,7 @@ 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``
---------------------
@ -273,6 +285,21 @@ 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.
``CONSOLE_TYPE``
----------------
.. versionadded:: 2013.2(Havana)
Default: ``"AUTO"``
This settings specifies the type of in-browser VNC console used to access the
VMs.
Valid values are ``"AUTO"``(default), ``"VNC"``, ``"SPICE"``, ``"RDP"``
and ``None`` (this latest value is available in version 2014.2(Juno) to allow
deactivating the in-browser console).
``CREATE_INSTANCE_FLAVOR_SORT``
-------------------------------
@ -283,8 +310,9 @@ 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.
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::
@ -324,6 +352,35 @@ 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.
``OPENSTACK_API_VERSIONS``
--------------------------
.. versionadded:: 2013.2(Havana)
Default::
{
"data_processing": 1.1,
"identity": 2.0,
"volume": 1
}
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
}
``OPENSTACK_ENABLE_PASSWORD_RETRIEVE``
--------------------------------------
@ -442,6 +499,7 @@ service tend to be particularly large - in the order of hundreds of megabytes
to multiple gigabytes.
.. 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.
@ -460,6 +518,17 @@ 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``
-----------------------------------
@ -471,6 +540,17 @@ 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_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``
--------------------------
@ -511,7 +591,7 @@ Default::
'enable_vpn': True,
'profile_support': None,
'supported_provider_types': ["*"],
'segmentation_id_range': None
'segmentation_id_range': {}
}
A dictionary of settings which can be used to enable optional services provided
@ -564,46 +644,15 @@ option appropriately depending on your deployment.
Default: ``True``
Enables the load balancer panel. load balancer panel will be enabled
when this option is True and your Neutron deployment supports
LBaaS. If you want to disable load balancer panel even when your
Neutron supports LBaaS, set it to False.
Enables the load balancer panel. The load balancer panel will be enabled when
this option is True and your Neutron deployment supports LBaaS. If you want
to disable load balancer panel even when your Neutron supports LBaaS, set it to False.
This option is now marked as "deprecated" and will be removed in
Kilo or later release. The load balancer panel is now enabled only
when LBaaS feature is available in Neutron and this option is no
longer needed. We suggest not to use this option to disable the
This option is now marked as "deprecated" and will be removed in Kilo or later release.
The load balancer panel is now enabled only when LBaaS feature is available in Neutron
and this option is no longer needed. We suggest not to use this option to disable the
load balancer panel from now on.
``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 include
local, flat, vlan, gre, and vxlan. By default all provider network types will
be available to choose from.
Example: ``['local', 'flat', 'gre']``
``segmentation_id_range``:
.. versionadded:: 2014.2(Juno)
Default: ``None``
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]}``
``enable_quotas``:
Default: ``False``
@ -653,6 +702,36 @@ 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 include
local, flat, vlan, gre, and vxlan. By default all provider network types will
be available to choose from.
Example: ``['local', 'flat', 'gre']``
``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]}``
``OPENSTACK_SSL_CACERT``
------------------------
@ -720,16 +799,19 @@ 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.
``CONSOLE_TYPE``
-------------------------------------
Default: ``"AUTO"``
``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 ``[!]``.
This settings specifies the type of in-browser VNC console used to access the
VMs.
Valid values are ``"AUTO"``(default), ``"VNC"``, ``"SPICE"``, ``"RDP"`` and
``None``(this latest value is available in version 2014.2(Juno) to allow
deactivating the in-browser console).
``OPENSTACK_TOKEN_HASH_ALGORITHM``
----------------------------------
@ -768,7 +850,13 @@ 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 for versions of Django 1.5 and newer.
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`` and ``TEMPLATE_DEBUG``
--------------------------------
@ -793,9 +881,28 @@ 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``
---------------------------------------------------------------------------------
@ -805,6 +912,10 @@ 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.
.. _pluggable-settings-label:
Pluggable Settings