Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud 8

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.

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-memcached installed.

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

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.

  1. Start the MySQL command-line client.

    $ mysql -u root -p
  2. Enter the MySQL root user's password when prompted.

  3. To configure the MySQL database, create the dash database.

    mysql> CREATE DATABASE dash;
  4. 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';
  5. Enter quit at the mysql> prompt to exit MySQL.

  6. 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'
        }
    }
  7. 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
  8. 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.
  9. 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
  10. Restart the Apache service.

  11. On Ubuntu, restart the nova-api service 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.

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Images category. The images that you can administer for cloud users appear on this page.

  3. Click Create Image, which opens the Create An Image window.

    Figure Dashboard — Create Image
    Figure 4.1: Figure Dashboard — Create Image
  4. In the Create An Image window, enter or select the following values:

    Name

    Enter a name for the image.

    Description

    Enter a brief description of the image.

    Image Source

    Choose the image source from the dropdown list. Your choices are Image Location and Image File.

    Image File or Image Location

    Based on your selection, there is an Image File or Image Location field. You can include the location URL or browse for the image file on your file system and add it.

    Format

    Select the image format.

    Architecture

    Specify the architecture. For example, i386 for a 32-bit architecture or x86_64 for a 64-bit architecture.

    Minimum Disk (GB)

    Leave this field empty.

    Minimum RAM (MB)

    Leave this field empty.

    Copy Data

    Specify this option to copy image data to the Image service.

    Public

    Select this option to make the image public to all users.

    Protected

    Select this option to ensure that only users with permissions can delete it.

  5. Click Create Image.

    The image is queued to be uploaded. It might take several minutes before the status changes from Queued to Active.

4.3.2 Update images

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Images category.

  3. Select the images that you want to edit. Click Edit Image.

  4. In the Edit Image window, you can change the image name.

    Select the Public check box to make the image public. Clear this check box to make the image private. You cannot change the Kernel ID, Ramdisk ID, or Architecture attributes for an image.

  5. Click Edit Image.

4.3.3 Delete images

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Images category.

  3. Select the images that you want to delete.

  4. Click Delete Images.

  5. In the Confirm Delete Images window, click Delete Images 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.

Note
Note

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

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Identity tab, click the Roles category.

  3. Click the Create Role button.

    In the Create Role window, enter a name for the role.

  4. Click the Create Role button to confirm your changes.

4.4.2 Edit a role

  1. Log in to the dashboard and select the Identity project from the drop-down list.

  2. On the Identity tab, click the Roles category.

  3. Click the Edit button.

    In the Update Role window, enter a new name for the role.

  4. Click the Update Role button to confirm your changes.

Note
Note

Using the dashboard, you can edit only the name assigned to a role.

4.4.3 Delete a role

  1. Log in to the dashboard and select the Identity project from the drop-down list.

  2. On the Identity tab, click the Roles category.

  3. Select the role you want to delete and click the Delete Roles button.

  4. In the Confirm Delete Roles window, click Delete Roles 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

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Instances category.

  3. Select an instance to create a snapshot from it. From the Actions drop-down list, select Create Snapshot.

  4. In the Create Snapshot window, enter a name for the snapshot.

  5. Click Create Snapshot. The Dashboard shows the instance snapshot in the Images category.

  6. To launch an instance from the snapshot, select the snapshot and click Launch. For information about launching instances, see the OpenStack End User Guide.

4.5.2 Control the state of an instance

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Instances category.

  3. Select the instance for which you want to change the state.

  4. 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).

Figure Dashboard — Instance Actions
Figure 4.2: Figure Dashboard — Instance Actions

4.5.3 Track usage

Use the Overview 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.

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Overview category.

  3. Select a month and click Submit to query the instance usage for that month.

  4. Click Download CSV Summary 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

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. In the Admin tab, open the System tab and click the Flavors category.

  3. Click Create Flavor.

  4. In the Create Flavor window, enter or select the parameters for the flavor in the Flavor Information tab.

    Dashboard — Create Flavor
    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.

  5. In the Flavor Access tab, you can control access to the flavor by moving projects from the All Projects column to the Selected Projects column.

    Only projects in the Selected Projects column can use the flavor. If there are no projects in the right column, all projects can use the flavor.

  6. Click Create Flavor.

4.6.2 Update flavors

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. In the Admin tab, open the System tab and click the Flavors category.

  3. Select the flavor that you want to edit. Click Edit Flavor.

  4. In the Edit Flavor window, you can change the flavor name, VCPUs, RAM, root disk, ephemeral disk, and swap disk values.

  5. Click Save.

4.6.3 Update Metadata

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. In the Admin tab, open the System tab and click the Flavors category.

  3. Select the flavor that you want to update. In the drop-down list, click Update Metadata or click No or Yes in the Metadata column.

  4. In the Update Flavor Metadata window, you can customize some metadata keys, then add it to this flavor and set them values.

  5. Click Save.

    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

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. In the Admin tab, open the System tab and click the Flavors category.

  3. Select the flavors that you want to delete.

  4. Click Delete Flavors.

  5. In the Confirm Delete Flavors window, click Delete Flavors 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

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Volumes category.

  3. Click the Volume Types tab, and click Create Volume Type button. In the Create Volume Type window, enter a name for the volume type.

  4. Click Create Volume Type button to confirm your changes.

Note
Note

A message indicates whether the action succeeded.

4.7.2 Create an encrypted volume type

  1. Create a volume type using the steps above for Section 4.7.1, “Create a volume type”.

  2. Click Create Encryption in the Actions column of the newly created volume type.

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

  4. Click Create Volume Type Encryption.

Encryption Options
Figure 4.4: Encryption Options

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.

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Volumes category.

  3. Click the Volume Types tab, select the volume type or types that you want to delete.

  4. Click Delete Volume Types button.

  5. In the Confirm Delete Volume Types window, click the Delete Volume Types button to confirm the action.

Note
Note

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.

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Volumes category.

  3. Select the volume or volumes that you want to delete.

  4. Click Delete Volumes button.

  5. In the Confirm Delete Volumes window, click the Delete Volumes button to confirm the action.

Note
Note

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

  1. Log in to the Dashboard and choose the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Shares category.

  3. Click the Share Types tab, and click Create Share Type button. In the Create Share Type window, enter or select the following values.

    Name: Enter a name for the share type.

    Driver handles share servers: Choose True or False

    Extra specs: To add extra specs, use key=value.

  4. Click Create Share Type button to confirm your changes.

Note
Note

A message indicates whether the action succeeded.

4.8.2 Update share type

  1. Log in to the Dashboard and choose the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Shares category.

  3. Click the Share Types tab, select the share type that you want to update.

  4. Select Update Share Type from Actions.

  5. In the Update Share Type window, update extra specs.

    Extra specs: To add extra specs, use key=value. To unset extra specs, use key.

  6. Click Update Share Type button to confirm your changes.

Note
Note

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.

  1. Log in to the Dashboard and choose the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Shares category.

  3. Click the Share Types tab, select the share type or types that you want to delete.

  4. Click Delete Share Types button.

  5. In the Confirm Delete Share Types window, click the Delete Share Types button to confirm the action.

Note
Note

A message indicates whether the action succeeded.

4.8.4 Delete shares

  1. Log in to the Dashboard and choose the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Shares category.

  3. Select the share or shares that you want to delete.

  4. Click Delete Shares button.

  5. In the Confirm Delete Shares window, click the Delete Shares button to confirm the action.

Note
Note

A message indicates whether the action succeeded.

4.8.5 Delete share server

  1. Log in to the Dashboard and choose the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Share Servers category.

  3. Select the share that you want to delete.

  4. Click Delete Share Server button.

  5. In the Confirm Delete Share Server window, click the Delete Share Server button to confirm the action.

Note
Note

A message indicates whether the action succeeded.

4.8.6 Delete share networks

  1. Log in to the Dashboard and choose the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Share Networks category.

  3. Select the share network or share networks that you want to delete.

  4. Click Delete Share Networks button.

  5. In the Confirm Delete Share Networks window, click the Delete Share Networks button to confirm the action.

Note
Note

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.

Note
Note

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

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Defaults category.

  3. The default quota values are displayed.

Note
Note

You can sort the table by clicking on either the Quota Name or Limit column headers.

4.9.2 Update project quotas

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Defaults category.

  3. Click the Update Defaults button.

  4. In the Update Default Quotas window, you can edit the default quota values.

  5. Click the Update Defaults button.

Note
Note

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.

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the System Information category.

    View the following information on these tabs:

    • Services: 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.

    • Compute Services: Displays information specific to the Compute service. Both host and zone are listed for each service, as well as its activation status.

    • Block Storage Services: Displays information specific to the Block Storage service. Both host and zone are listed for each service, as well as its activation status.

    • Network Agents: Displays the network agents active within the cluster, such as L3 and DHCP agents, and the status of each agent.

    • Orchestration Services: 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).

Note
Note

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

  1. Log in to the dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, click the Resource Usage category.

  3. Click the:

    • Usage Report tab to view a usage report per project by specifying the time period (or even use a calendar to define a date range).

    • Stats 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

  1. Log in to the Dashboard and select the admin project from the drop-down list.

  2. On the Admin tab, open the System tab and click the Host Aggregates category.

  3. Click Create Host Aggregate.

  4. In the Create Host Aggregate dialog box, enter or select the following values on the Host Aggregate Information tab:

    • Name: The host aggregate name.

    • Availability Zone: The cloud provider defines the default availability zone, such as 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.

  5. Assign hosts to the aggregate using the Manage Hosts within Aggregate tab in the same dialog box.

    To assign a host to the aggregate, click + for the host. The host moves from the All available hosts list to the Selected hosts 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

  1. Select the admin project from the drop-down list at the top of the page.

  2. On the Admin tab, open the System tab and click the Host Aggregates category.

    • To edit host aggregates, select the host aggregate that you want to edit. Click Edit Host Aggregate.

      In the Edit Host Aggregate 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 More and select Manage Hosts.

      In the Add/Remove Hosts to Aggregate 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 More and select Delete Host Aggregate.

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:

Print this page