Installs the OpenStack Dashboard service Horizon as part of the OpenStack reference deployment Chef for OpenStack. The http://github.com/mattray/chef-openstack-repo contains documentation for using this cookbook in the context of a full OpenStack deployment. Horizon is currently installed from packages.
- Chef 0.10.0 or higher required (for Chef environment use).
The following cookbooks are dependencies:
- apache2
- openstack-common
Sets up the Horizon dashboard within an Apache mod_wsgi container.
"run_list": [
"recipe[openstack-dashboard::server]"
]openstack['dashboard']['db']['username']- Username for horizon database accessopenstack['dashboard']['server_hostname']- Sets the ServerName in the Apache configopenstack['dashboard']['allowed_hosts']- List of host/domain names we can service (default: '[*]')openstack['dashboard']['dash_path']- Base path for dashboard files (document root)openstack['dashboard']['wsgi_path']- Path for wsgi diropenstack['dashboard']['wsgi_socket_prefix']- Location that will override the standard Apache runtime directoryopenstack['dashboard']['ssl_offload']- Set SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOCOL', 'https') flag for offloading SSLopenstack['dashboard']['plugins']- Array of plugins to include via INSTALED_APPSopenstack['dashboard']['simple_ip_management']- Boolean to enable or disable simplified floating IP address managementopenstack['dashboard']['http_port']- Port that httpd should listen on (default: 80)openstack['dashboard']['https_port']- Port that httpd should listen on for using ssl (default: 443)openstack['dashboard']['password_autocomplete']- Toggle browser autocompletion for login form ('on' or 'off', default: 'on')openstack['dashboard']['misc_local_settings']- Additions to the local_settings conf file
openstack['dashboard']['identity_api_version']- Force a specific Identity API version ('2.0' or '3', default: '2.0')openstack['dashboard']['keystone_multidomain_support']- Boolean to enable multi-Domain supportopenstack['dashboard']['keystone_default_domain']- Default Domain if using API v3 and on a single-domain model (default: 'Default')openstack['dashboard']['keystone_default_role']- Default Keystone role assigned to project members (default: 'member')openstack['dashboard']['keystone_backend']['name']- Keystone backend in use ('native' or 'ldap', default: 'native')openstack['dashboard']['keystone_backend']['can_edit_user']- Boolean to allow some user-related identity operations (default: true)openstack['dashboard']['keystone_backend']['can_edit_group']- Boolean to allow some group-related identity operations (default: true)openstack['dashboard']['keystone_backend']['can_edit_project']- Boolean to allow some project-related identity operations (default: true)openstack['dashboard']['keystone_backend']['can_edit_domain']- Boolean to allow some domain-related identity operations (default: true)openstack['dashboard']['keystone_backend']['can_edit_role']- Boolean to allow some role-related identity operations (default: true)
openstack['dashboard']['use_ssl']- Toggle for using ssl with dashboard (default: true)openstack['dashboard']['ssl']['dir']- Directory where ssl certs are stored on this system (default: platform dependent)openstack['dashboard']['ssl']['cert']- Name to use when creating the ssl certificateopenstack['dashboard']['ssl']['cert_url']- If using an existing certificate, this is the URL to its locationopenstack['dashboard']['ssl']['key']- Name to use when creating the ssl keyopenstack['dashboard']['ssl']['key_url']- If using an existing certificate key, this is the URL to its location
By default the openstack-dashboard cookbook ships with a self-signed certificate from a fake organization. It is possible to use a real production certificate from your organization by putting that certificate somewhere where the cookbook can download it from then simply passing in the URL of the certificate, and its corresponding key, using the 'cert_url' and 'key_url' attributes.
Please refer to the TESTING.md for instructions for testing the cookbook.
Berks will resolve version requirements and dependencies on first run and
store these in Berksfile.lock. If new cookbooks become available you can run
berks update to update the references in Berksfile.lock. Berksfile.lock will
be included in stable branches to provide a known good set of dependencies.
Berksfile.lock will not be included in development branches to encourage
development against the latest cookbooks.
| Author | Justin Shepherd ([email protected]) |
| Author | Jason Cannavale ([email protected]) |
| Author | Ron Pedde ([email protected]) |
| Author | Joseph Breu ([email protected]) |
| Author | William Kelly ([email protected]) |
| Author | Darren Birkett ([email protected]) |
| Author | Evan Callicoat ([email protected]) |
| Author | Jay Pipes ([email protected]) |
| Author | John Dewey ([email protected]) |
| Author | Matt Ray ([email protected]) |
| Author | Sean Gallagher ([email protected]) |
| Author | Chen Zhiwei ([email protected]) |
| Author | Jian Hua Geng ([email protected]) |
| Author | Ionut Artarisi ([email protected]) |
| Author | Eric Zhou ([email protected]) |
| Copyright | Copyright (c) 2012, Rackspace US, Inc. |
| Copyright | Copyright (c) 2012-2013, AT&T Services, Inc. |
| Copyright | Copyright (c) 2013, Opscode, Inc. |
| Copyright | Copyright (c) 2013-2014, IBM, Corp. |
| Copyright | Copyright (c) 2013-2014, SUSE Linux GmbH. |
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.