4 Dashboard #
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.
4.1 Customize and configure the Dashboard #
For information on this topic, see the SUSE OpenStack Supplement Guide, available at https://documentation.suse.com/soc/8/single-html/suse-openstack-cloud-supplement.
4.2 Set up session storage for the Dashboard #
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.
4.2.1 Local memory cache #
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.
4.2.1.1 Memcached #
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-memcachedinstalled.
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': 'my_memcached_host:11211',
}
}4.2.1.2 Redis #
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
redisanddjango-redisinstalled.
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",
}
}
}4.2.1.3 Initialize and configure the database #
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
quitat themysql>prompt to exit MySQL.In the
local_settings.pyfile, 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.pyfile as shown, you can run themanage.py syncdbcommand 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
blackholedirectory in the Dashboard directory, as follows.# mkdir -p /var/lib/dash/.blackhole
Restart the Apache service.
On Ubuntu, restart the
nova-apiservice to ensure that the API server can connect to the Dashboard without error.# service nova-api restart
4.2.2 Cached database #
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"4.2.3 Cookies #
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.
4.3 Create and manage images #
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.
4.3.1 Create images #
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.
Figure 4.1: Figure Dashboard — Create Image #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,
i386for a 32-bit architecture orx86_64for a 64-bit architecture.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
QueuedtoActive.
4.3.2 Update images #
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 .
4.3.3 Delete images #
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.
4.4 Create and manage roles #
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.
4.4.1 Create a role #
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.
4.4.2 Edit a role #
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.
4.4.3 Delete 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.
4.5 Manage instances #
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.
4.5.1 Create instance snapshots #
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 . For information about launching instances, see the OpenStack End User Guide.
4.5.2 Control the state of an instance #
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 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).
4.5.3 Track usage #
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.
4.6 Manage flavors #
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 |
4.6.1 Create 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.
Click .
In the window, enter or select the parameters for the flavor in the tab.
Figure 4.3: Dashboard — Create Flavor #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 .
4.6.2 Update 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 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 .
4.6.3 Update Metadata #
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”.
4.6.4 Delete 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.
4.7 Manage volumes and volume types #
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.
4.7.1 Create a volume type #
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.
4.7.2 Create an encrypted volume type #
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):
- Provider
Specifies the class responsible for configuring the encryption.
- Control Location
Specifies whether the encryption is from the front end (nova) or the back end (cinder).
- Cipher
Specifies the encryption algorithm.
- Key Size (bits)
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
4.7.3 Delete volume types #
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.
4.7.4 Delete volumes #
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.
4.8 Manage shares and share types #
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.
4.8.1 Create a share type #
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.
4.8.2 Update share type #
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.
4.8.3 Delete share types #
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.
4.8.4 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.
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.
4.8.5 Delete share server #
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.
4.8.6 Delete share networks #
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.
4.9 View and manage quotas #
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 |
4.9.1 View default project quotas #
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.
4.9.2 Update project quotas #
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.
4.10 View cloud resources #
4.10.1 View services information #
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.
4.10.2 View cloud usage statistics #
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.
4.10.2.1 View resource statistics #
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).
4.11 Create and manage host aggregates #
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.
4.11.1 To create a host aggregate #
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.
: The cloud provider defines the default availability zone, such as
us-west,apac-south, ornova. 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.
4.11.2 To manage host aggregates #
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 dialog box, click + to assign a host to an aggregate. Click - to remove a host that is assigned to an aggregate.
To delete host aggregates, locate the host aggregate that you want to edit in the table. Click and select .
4.12 Launch and manage stacks using the Dashboard #
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.
NoteThere 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.



