The OpenStack Dashboard is a web-based interface that allows you to manage OpenStack resources and services. The Dashboard allows you to interact with the OpenStack Compute cloud controller using the OpenStack APIs. For more information about installing and configuring the Dashboard, see the Installation Tutorials and Guides for your operating system.
To deploy the dashboard, see the OpenStack dashboard documentation.
To launch instances with the dashboard as an end user, see the Launch and manage instances. in the OpenStack End User Guide.
To create and manage ports, see the Create and manage networks section of the OpenStack End User Guide.
For information on this topic, see the SUSE OpenStack Supplement Guide, available from https://www.suse.com/documentation/cloud/.
The Dashboard uses Django sessions
framework
to handle user session data. However, you can use any available session
back end. You customize the session back end through the
SESSION_ENGINE
setting in your local_settings.py
file.
After architecting and implementing the core OpenStack services and other required services, combined with the Dashboard service steps below, users and administrators can use the OpenStack dashboard. Refer to the OpenStack Dashboard chapter of the OpenStack End User Guide for further instructions on logging in to the Dashboard.
The following sections describe the pros and cons of each option as it pertains to deploying the Dashboard.
Local memory storage is the quickest and easiest session back end to set up, as it has no external dependencies whatsoever. It has the following significant drawbacks:
No shared storage across processes or workers.
No persistence after a process terminates.
The local memory back end is enabled as the default for Horizon solely because it has no dependencies. It is not recommended for production use, or even for serious development work.
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
'default' : {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache'
}
}
You can use applications such as Memcached
or Redis
for external
caching. These applications offer persistence and shared storage and are
useful for small-scale deployments and development.
Memcached is a high-performance and distributed memory object caching system providing in-memory key-value store for small chunks of arbitrary data.
Requirements:
Memcached service running and accessible.
Python module python-memcached
installed.
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': 'my_memcached_host:11211',
}
}
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server.
Requirements:
Redis service running and accessible.
Python modules redis
and django-redis
installed.
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
"default": {
"BACKEND": "redis_cache.cache.RedisCache",
"LOCATION": "127.0.0.1:6379:1",
"OPTIONS": {
"CLIENT_CLASS": "redis_cache.client.DefaultClient",
}
}
}
Database-backed sessions are scalable, persistent, and can be made high-concurrency and highly available.
However, database-backed sessions are one of the slower session storages and incur a high overhead under heavy usage. Proper configuration of your database deployment can also be a substantial undertaking and is far beyond the scope of this documentation.
Start the MySQL command-line client.
$ mysql -u root -p
Enter the MySQL root user's password when prompted.
To configure the MySQL database, create the dash database.
mysql> CREATE DATABASE dash;
Create a MySQL user for the newly created dash database that has full control of the database. Replace DASH_DBPASS with a password for the new user.
mysql> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'%' IDENTIFIED BY 'DASH_DBPASS'; mysql> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'localhost' IDENTIFIED BY 'DASH_DBPASS';
Enter quit
at the mysql>
prompt to exit MySQL.
In the local_settings.py
file, change these options:
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
DATABASES = {
'default': {
# Database configuration here
'ENGINE': 'django.db.backends.mysql',
'NAME': 'dash',
'USER': 'dash',
'PASSWORD': 'DASH_DBPASS',
'HOST': 'localhost',
'default-character-set': 'utf8'
}
}
After configuring the local_settings.py
file as shown, you can run the
manage.py syncdb
command to populate this newly created
database.
# /usr/share/openstack-dashboard/manage.py syncdb
The following output is returned:
Installing custom SQL ... Installing indexes ... DEBUG:django.db.backends:(0.008) CREATE INDEX `django_session_c25c2c28` ON `django_session` (`expire_date`);; args=() No fixtures found.
To avoid a warning when you restart Apache on Ubuntu, create a
blackhole
directory in the Dashboard directory, as follows.
# mkdir -p /var/lib/dash/.blackhole
Restart the Apache service.
On Ubuntu, restart the nova-api
service to ensure that the API server
can connect to the Dashboard without error.
# service nova-api restart
To mitigate the performance issues of database queries, you can use the
Django cached_db
session back end, which utilizes both your database
and caching infrastructure to perform write-through caching and
efficient retrieval.
Enable this hybrid setting by configuring both your database and cache, as discussed previously. Then, set the following value:
SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"
If you use Django 1.4 or later, the signed_cookies
back end avoids
server load and scaling problems.
This back end stores session data in a cookie, which is stored by the user's browser. The back end uses a cryptographic signing technique to ensure session data is not tampered with during transport. This is not the same as encryption; session data is still readable by an attacker.
The pros of this engine are that it requires no additional dependencies or infrastructure overhead, and it scales indefinitely as long as the quantity of session data being stored fits into a normal cookie.
The biggest downside is that it places session data into storage on the user's machine and transports it over the wire. It also limits the quantity of session data that can be stored.
See the Django cookie-based sessions documentation.
As an administrative user, you can create and manage images for the projects to which you belong. You can also create and manage images for users in all projects to which you have access.
To create and manage images in specified projects as an end user, see the upload and manage images with Dashboard in OpenStack End User Guide and manage images with CLI in OpenStack End User Guide .
To create and manage images as an administrator for other users, use the following procedures.
For details about image creation, see the Virtual Machine Image Guide.
Log in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category. The images that you can administer for cloud users appear on this page.Click
, which opens the window.In the
window, enter or select the following values:
|
Enter a name for the image. |
|
Enter a brief description of the image. |
|
Choose the image source from the dropdown list. Your choices are and . |
or |
Based on your selection, there is an or field. You can include the location URL or browse for the image file on your file system and add it. |
|
Select the image format. |
|
Specify the architecture. For
example, |
|
Leave this field empty. |
|
Leave this field empty. |
|
Specify this option to copy image data to the Image service. |
|
Select this option to make the image public to all users. |
|
Select this option to ensure that only users with permissions can delete it. |
Click
.The image is queued to be uploaded. It might take several minutes
before the status changes from Queued
to Active
.
Log in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Select the images that you want to edit. Click
.In the
window, you can change the image name.Select the
check box to make the image public. Clear this check box to make the image private. You cannot change the , , or attributes for an image.Click
.Log in to the Dashboard and select the
project from the drop-down list.On the
, open the tab and click the category.Select the images that you want to delete.
Click
.In the
window, click to confirm the deletion.You cannot undo this action.
A role is a personality that a user assumes to perform a specific set of operations. A role includes a set of rights and privileges. A user assumes that role inherits those rights and privileges.
OpenStack Identity service defines a user's role on a
project, but it is completely up to the individual service
to define what that role means. This is referred to as the
service's policy. To get details about what the privileges
for each role are, refer to the policy.json
file
available for each service in the
/etc/SERVICE/policy.json
file. For example, the
policy defined for OpenStack Identity service is defined
in the /etc/keystone/policy.json
file.
Log in to the dashboard and select the
project from the drop-down list.On the
tab, click the category.Click the
button.In the
window, enter a name for the role.Click the
button to confirm your changes.Log in to the dashboard and select the
project from the drop-down list.On the
tab, click the category.Click the
button.In the
window, enter a new name for the role.Click the
button to confirm your changes.Using the dashboard, you can edit only the name assigned to a role.
Log in to the dashboard and select the
project from the drop-down list.On the
tab, click the category.Select the role you want to delete and click the
button.In the
window, click to confirm the deletion.You cannot undo this action.
As an administrative user, you can manage instances for users in various projects. You can view, terminate, edit, perform a soft or hard reboot, create a snapshot from, and migrate instances. You can also view the logs for instances or launch a VNC console for an instance.
For information about using the Dashboard to launch instances as an end user, see the OpenStack End User Guide.
Log in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Select an instance to create a snapshot from it. From the Actions drop-down list, select
.In the
window, enter a name for the snapshot.Click
. The Dashboard shows the instance snapshot in the category.To launch an instance from the snapshot, select the snapshot and click OpenStack End User Guide.
. For information about launching instances, see theLog in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Select the instance for which you want to change the state.
From the drop-down list in the Actions column, select the state.
Depending on the current state of the instance, you can perform various actions on the instance. For example, pause, un-pause, suspend, resume, soft or hard reboot, or terminate (actions in red are dangerous).
Use the
category to track usage of instances for each project.You can track costs per month by showing meters like number of VCPUs, disks, RAM, and uptime of all your instances.
Log in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Select a month and click
to query the instance usage for that month.Click
to download a CSV summary.In OpenStack, a flavor defines the compute, memory, and storage capacity of a virtual server, also known as an instance. As an administrative user, you can create, edit, and delete flavors.
As of Newton, there are no default flavors. The following table lists the default flavors for Mitaka and earlier.
Flavor |
VCPUs |
Disk (in GB) |
RAM (in MB) |
---|---|---|---|
m1.tiny |
1 |
1 |
512 |
m1.small |
1 |
20 |
2048 |
m1.medium |
2 |
40 |
4096 |
m1.large |
4 |
80 |
8192 |
m1.xlarge |
8 |
160 |
16384 |
Log in to the Dashboard and select the
project from the drop-down list.In the
tab, open the tab and click the category.Click
.In the
window, enter or select the parameters for the flavor in the tab.
Name |
Enter the flavor name. |
ID |
Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be automatically generated. |
VCPUs |
Enter the number of virtual CPUs to use. |
RAM (MB) |
Enter the amount of RAM to use, in megabytes. |
Root Disk (GB) |
Enter the amount of disk space in gigabytes to use for the root (/) partition. |
Ephemeral Disk (GB) |
Enter the amount of disk space in gigabytes to use for the ephemeral partition. If unspecified, the value is 0 by default. Ephemeral disks offer machine local disk storage linked to the lifecycle of a VM instance. When a VM is terminated, all data on the ephemeral disk is lost. Ephemeral disks are not included in any snapshots. |
Swap Disk (MB) |
Enter the amount of swap space (in megabytes) to use. If unspecified, the default is 0. |
RX/TX Factor |
Optional property allows servers with a different bandwidth to be created with the RX/TX Factor. The default value is 1. That is, the new bandwidth is the same as that of the attached network. |
In the
tab, you can control access to the flavor by moving projects from the column to the column.Only projects in the
column can use the flavor. If there are no projects in the right column, all projects can use the flavor.Click
.Log in to the Dashboard and select the
project from the drop-down list.In the
tab, open the tab and click the category.Select the flavor that you want to edit. Click
.In the
window, you can change the flavor name, VCPUs, RAM, root disk, ephemeral disk, and swap disk values.Click
.Log in to the Dashboard and select the
project from the drop-down list.In the
tab, open the tab and click the category.Select the flavor that you want to update. In the drop-down list, click
or click or in the column.In the
window, you can customize some metadata keys, then add it to this flavor and set them values.Click
.Optional metadata keys
CPU limits |
quota:cpu_shares |
quota:cpu_period | |
quota:cpu_limit | |
quota:cpu_reservation | |
quota:cpu_quota | |
Disk tuning |
quota:disk_read_bytes_sec |
quota:disk_read_iops_sec | |
quota:disk_write_bytes_sec | |
quota:disk_write_iops_sec | |
quota:disk_total_bytes_sec | |
quota:disk_total_iops_sec | |
Bandwidth I/O |
quota:vif_inbound_average |
quota:vif_inbound_burst | |
quota:vif_inbound_peak | |
quota:vif_outbound_average | |
quota:vif_outbound_burst | |
quota:vif_outbound_peak | |
Watchdog behavior |
hw:watchdog_action |
Random-number generator |
hw_rng:allowed |
hw_rng:rate_bytes | |
hw_rng:rate_period |
For information about supporting metadata keys, see the Section 5.4.3, “Flavors”.
Log in to the Dashboard and select the
project from the drop-down list.In the
tab, open the tab and click the category.Select the flavors that you want to delete.
Click
.In the
window, click to confirm the deletion. You cannot undo this action.Volumes are the Block Storage devices that you attach to instances to enable persistent storage. Users can attach a volume to a running instance or detach a volume and attach it to another instance at any time. For information about using the dashboard to create and manage volumes as an end user, see the OpenStack End User Guide.
As an administrative user, you can manage volumes and volume types for users in various projects. You can create and delete volume types, and you can view and delete volumes. Note that a volume can be encrypted by using the steps outlined below.
Log in to the dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Click the
tab, and click button. In the window, enter a name for the volume type.Click
button to confirm your changes.A message indicates whether the action succeeded.
Create a volume type using the steps above for Section 4.7.1, “Create a volume type”.
Click
in the Actions column of the newly created volume type.Configure the encrypted volume by setting the parameters below from available options (see table):
Specifies the class responsible for configuring the encryption.
Specifies whether the encryption is from the front end (nova) or the back end (cinder).
Specifies the encryption algorithm.
Specifies the encryption key size.
Click
.The table below provides a few alternatives available for creating encrypted volumes.
Encryption parameters |
Parameter options |
Comments |
---|---|---|
Provider |
nova.volume.encryptors. luks.LuksEncryptor (Recommended) |
Allows easier import and migration of imported encrypted volumes, and allows access key to be changed without re-encrypting the volume |
nova.volume.encryptors. cryptsetup. CryptsetupEncryptor |
Less disk overhead than LUKS | |
Control Location |
front-end (Recommended) |
The encryption occurs within nova so that the data transmitted over the network is encrypted |
back-end |
This could be selected if a cinder plug-in supporting an encrypted back-end block storage device becomes available in the future. TLS or other network encryption would also be needed to protect data as it traverses the network | |
Cipher |
aes-xts-plain64 (Recommended) |
See NIST reference below to see advantages* |
aes-cbc-essiv |
Note: On the command line, type 'cryptsetup benchmark' for additional options | |
Key Size (bits) |
512 (Recommended for aes-xts-plain64. 256 should be used for aes-cbc-essiv) |
Using this selection for aes-xts, the underlying key size would only be 256-bits* |
256 |
Using this selection for aes-xts, the underlying key size would only be 128-bits* |
*
Source NIST SP 800-38E
When you delete a volume type, volumes of that type are not deleted.
Log in to the dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Click the
tab, select the volume type or types that you want to delete.Click
button.In the
window, click the button to confirm the action.A message indicates whether the action succeeded.
When you delete an instance, the data of its attached volumes is not destroyed.
Log in to the dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Select the volume or volumes that you want to delete.
Click
button.In the
window, click the button to confirm the action.A message indicates whether the action succeeded.
Shares are file storage that instances can access. Users can allow or deny a running instance to have access to a share at any time. For information about using the Dashboard to create and manage shares as an end user, see the OpenStack End User Guide.
As an administrative user, you can manage shares and share types for users in various projects. You can create and delete share types, and view or delete shares.
Log in to the Dashboard and choose the
project from the drop-down list.On the
tab, open the tab and click the category.Click the
tab, and click button. In the window, enter or select the following values.: Enter a name for the share type.
: Choose True or False
: To add extra specs, use key=value.
Click
button to confirm your changes.A message indicates whether the action succeeded.
Log in to the Dashboard and choose the
project from the drop-down list.On the
tab, open the tab and click the category.Click the
tab, select the share type that you want to update.Select
from Actions.In the
window, update extra specs.: To add extra specs, use key=value. To unset extra specs, use key.
Click
button to confirm your changes.A message indicates whether the action succeeded.
When you delete a share type, shares of that type are not deleted.
Log in to the Dashboard and choose the
project from the drop-down list.On the
tab, open the tab and click the category.Click the
tab, select the share type or types that you want to delete.Click
button.In the
window, click the button to confirm the action.A message indicates whether the action succeeded.
Log in to the Dashboard and choose the
project from the drop-down list.On the
tab, open the tab and click the category.Select the share or shares that you want to delete.
Click
button.In the
window, click the button to confirm the action.A message indicates whether the action succeeded.
Log in to the Dashboard and choose the
project from the drop-down list.On the
tab, open the tab and click the category.Select the share that you want to delete.
Click
button.In the
window, click the button to confirm the action.A message indicates whether the action succeeded.
Log in to the Dashboard and choose the
project from the drop-down list.On the
tab, open the tab and click the category.Select the share network or share networks that you want to delete.
Click
button.In the
window, click the button to confirm the action.A message indicates whether the action succeeded.
To prevent system capacities from being exhausted without notification, you can set up quotas. Quotas are operational limits. For example, the number of gigabytes allowed for each project can be controlled so that cloud resources are optimized. Quotas can be enforced at both the project and the project-user level.
Typically, you change quotas when a project needs more than ten volumes or 1 TB on a compute node.
Using the Dashboard, you can view default Compute and Block Storage quotas for new projects, as well as update quotas for existing projects.
Using the command-line interface, you can manage quotas for the OpenStack Compute service, the OpenStack Block Storage service, and the OpenStack Networking service (see OpenStack Administrator Guide). Additionally, you can update Compute service quotas for project users.
The following table describes the Compute and Block Storage service quotas:
Quota Descriptions
Quota Name |
Defines the number of |
Service |
---|---|---|
Gigabytes |
Volume gigabytes allowed for each project. |
Block Storage |
Instances |
Instances allowed for each project. |
Compute |
Injected Files |
Injected files allowed for each project. |
Compute |
Injected File Content Bytes |
Content bytes allowed for each injected file. |
Compute |
Keypairs |
Number of keypairs. |
Compute |
Metadata Items |
Metadata items allowed for each instance. |
Compute |
RAM (MB) |
RAM megabytes allowed for each instance. |
Compute |
Security Groups |
Security groups allowed for each project. |
Compute |
Security Group Rules |
Rules allowed for each security group. |
Compute |
Snapshots |
Volume snapshots allowed for each project. |
Block Storage |
VCPUs |
Instance cores allowed for each project. |
Compute |
Volumes |
Volumes allowed for each project. |
Block Storage |
Log in to the dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.The default quota values are displayed.
You can sort the table by clicking on either the
or column headers.Log in to the dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Click the
button.In the
window, you can edit the default quota values.Click the
button.The dashboard does not show all possible project quotas. To view and update the quotas for a service, use its command-line client. See OpenStack Administrator Guide.
As an administrative user, you can view information for OpenStack services.
Log in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.View the following information on these tabs:
: Displays the internal name and the public OpenStack name for each service, the host on which the service runs, and whether or not the service is enabled.
: Displays information specific to the Compute service. Both host and zone are listed for each service, as well as its activation status.
: Displays information specific to the Block Storage service. Both host and zone are listed for each service, as well as its activation status.
: Displays the network agents active within the cluster, such as L3 and DHCP agents, and the status of each agent.
: Displays information specific to the Orchestration service. Name, engine id, host and topic are listed for each service, as well as its activation status.
The Telemetry service provides user-level usage data for OpenStack-based clouds, which can be used for customer billing, system monitoring, or alerts. Data can be collected by notifications sent by existing OpenStack components (for example, usage events emitted from Compute) or by polling the infrastructure (for example, libvirt).
You can only view metering statistics on the dashboard (available
only to administrators).
The Telemetry service must be set up and administered through the
ceilometer
command-line interface (CLI).
For basic administration information, refer to the Measure Cloud Resources chapter in the OpenStack End User Guide.
Log in to the dashboard and select the
project from the drop-down list.On the
tab, click the category.Click the:
tab to view a usage report per project by specifying the time period (or even use a calendar to define a date range).
tab to view a multi-series line chart with user-defined meters. You group by project, define the value type (min, max, avg, or sum), and specify the time period (or even use a calendar to define a date range).
Host aggregates enable administrative users to assign key-value pairs to groups of machines.
Each node can have multiple aggregates and each aggregate can have multiple key-value pairs. You can assign the same key-value pair to multiple aggregates.
The scheduler uses this information to make scheduling decisions. For information, see Scheduling.
Log in to the Dashboard and select the
project from the drop-down list.On the
tab, open the tab and click the category.Click
.In the
dialog box, enter or select the following values on the tab:: The host aggregate name.
us-west
, apac-south
, or
nova
. You can target the host aggregate, as follows:
When the host aggregate is exposed as an availability zone, select the availability zone when you launch an instance.
When the host aggregate is not exposed as an availability zone, select a flavor and its extra specs to target the host aggregate.
Assign hosts to the aggregate using the
tab in the same dialog box.To assign a host to the aggregate, click + for the host. The host moves from the list to the list.
You can add one host to one or more aggregates. To add a host to an existing aggregate, edit the aggregate.
Select the
project from the drop-down list at the top of the page.On the
tab, open the tab and click the category.To edit host aggregates, select the host aggregate that you want to edit. Click
.In the
dialog box, you can change the name and availability zone for the aggregate.To manage hosts, locate the host aggregate that you want to edit in the table. Click
and select .In the + to assign a host to an aggregate. Click - to remove a host that is assigned to an aggregate.
dialog box, clickTo delete host aggregates, locate the host aggregate that you want to edit in the table. Click
and select .The Orchestration service provides a template-based orchestration engine for the OpenStack cloud. Orchestration services create and manage cloud infrastructure resources such as storage, networking, instances, and applications as a repeatable running environment.
Administrators use templates to create stacks, which are collections of resources. For example, a stack might include instances, floating IPs, volumes, security groups, or users. The Orchestration service offers access to all OpenStack core services via a single modular template, with additional orchestration capabilities such as auto-scaling and basic high availability.
For information about:
administrative tasks on the command-line, see the OpenStack Administrator Guide.
There are no administration-specific tasks that can be done through the Dashboard.
the basic creation and deletion of Orchestration stacks, refer to the OpenStack End User Guide.