Release Notes

The ability of the libvirt driver to set the admin password has been added. To use this feature, run the following command: "nova root-password [server]".

The ability of the libvirt driver to set the admin password has been added. To use this feature, run the following command: "nova root-password [server]".

You can now use VMWare vSAN data stores. These stores allow you to use vMotion while simultaneously using hypervisor-local storage for instances.

You can now use VMWare vSAN data stores. These stores allow you to use vMotion while simultaneously using hypervisor-local storage for instances.

The Orchestration service now includes an "OS::Heat::Stack" resource type. This OpenStack-native resource is used to explicitly create a child stack in a template. The "OS::Heat::Stack" resource type includes a 'context' property with a 'region_name' subproperty, allowing Orchestration service to manage stacks in different regions.

The Orchestration service now includes an "OS::Heat::Stack" resource type. This OpenStack-native resource is used to explicitly create a child stack in a template. The "OS::Heat::Stack" resource type includes a 'context' property with a 'region_name' subproperty, allowing Orchestration service to manage stacks in different regions.

You can now use VMware storage policy to manage how storage is assigned to different instances. This can help you ensure that instances are assigned to the most appropriate storage in an environment where multiple data stores (of varying costs and performance properties) are attached to a VMware infrastructure.

You can now use VMware storage policy to manage how storage is assigned to different instances. This can help you ensure that instances are assigned to the most appropriate storage in an environment where multiple data stores (of varying costs and performance properties) are attached to a VMware infrastructure.

Resources of type AWS::EC2::SecurityGroup can now be updated in-place when their rules are modified. This is consistent with the behaviour of AWS::EC2::SecurityGroup in CloudFormation. Previously, security groups would be replaced if they were modified.

Resources of type AWS::EC2::SecurityGroup can now be updated in-place when their rules are modified. This is consistent with the behaviour of AWS::EC2::SecurityGroup in CloudFormation. Previously, security groups would be replaced if they were modified.

This enhancement adds support for configuring multiple IPv6 prefixes and addresses on a single interface.
As a result, OpenStack Networking (neutron) considers the type of IPv6 subnets that form part of the network, and automatically associates ports with addresses from all the SLAAC-enabled subnets within the ports network.
There is no change to the REST API, but port-create/port-update responses automatically include the SLAAC addresses in the list of 'fixed_ips'.

This enhancement adds support for configuring multiple IPv6 prefixes and addresses on a single interface.
As a result, OpenStack Networking (neutron) considers the type of IPv6 subnets that form part of the network, and automatically associates ports with addresses from all the SLAAC-enabled subnets within the ports network.
There is no change to the REST API, but port-create/port-update responses automatically include the SLAAC addresses in the list of 'fixed_ips'.

Compute can now provide dedicated CPU resources, where each guest virtual CPU has full access to a specific host CPU.
Previous releases of Compute guest CPUswere permitted to float across any host CPU. Even when the NUMA feature was enabled, the CPUs could still float within a NUMA node. Host CPUs would  also overcommit so many virtual CPUs contended for the host resource. This made it impossible to provide strong performance guarantees to guest operating system workloads.
With this update, the cloud administrator now has the ability to set up a host aggregate, which provides a pool of hosts that supports guests with dedicated CPU resource assignment. The cloud administrator or tenant user can make use of these pools to run instances with guaranteed CPU resource.

Compute can now provide dedicated CPU resources, where each guest virtual CPU has full access to a specific host CPU.
Previous releases of Compute guest CPUswere permitted to float across any host CPU. Even when the NUMA feature was enabled, the CPUs could still float within a NUMA node. Host CPUs would  also overcommit so many virtual CPUs contended for the host resource. This made it impossible to provide strong performance guarantees to guest operating system workloads.
With this update, the cloud administrator now has the ability to set up a host aggregate, which provides a pool of hosts that supports guests with dedicated CPU resource assignment. The cloud administrator or tenant user can make use of these pools to run instances with guaranteed CPU resource.

OpenStack Trove instances can now be resized in the OpenStack dashboard user interface by selecting a new flavor for the instance.

OpenStack Trove instances can now be resized in the OpenStack dashboard user interface by selecting a new flavor for the instance.

The 'API Access' page in the dashboard ('Project > Compute > Access & Security > API Access') now provides more information on user credentials. To view this information, click 'View Credentials'. A pop-up displays the user name, project name, project ID, authentication URL, S3 URL, EC2 URL, EC2 access, and secret key.

The 'API Access' page in the dashboard ('Project > Compute > Access & Security > API Access') now provides more information on user credentials. To view this information, click 'View Credentials'. A pop-up displays the user name, project name, project ID, authentication URL, S3 URL, EC2 URL, EC2 access, and secret key.

The option to create Block Storage (cinder) volume transfers has been added to the 'Volumes' tab in the OpenStack dashboard. Volume transfers move ownership from one project to another. A donor creates a volume transfer, captures the resulting transfer ID and secret authentication key, and passes that information out of band to the recipient (such as by email or text message). The recipient accepts the transfer, supplying the transfer ID and authentication key. The ownership of the volume is then transferred from the donor to the recipient, and the volume is no longer visible to the donor.

Note the following limitations of the Block Storage API for volume transfers and their impact on the UI design:
1. When creating a volume transfer, you cannot specify who the intended recipient will be, and anyone with the transfer ID and authentication key can claim the volume. Therefore, the dashboard UI does not prompt for a recipient.
2. Current volume transfers are only visible to the donor; users in other projects are unable to view these transfers. So, the UI does not include a project table to view and accept volume transfers, since the current transfers are not visible. Instead, the transfer information is added to the volume details, which are visible by the donor, and the volume state clearly reflects that a transfer has been created. The UI also cannot present to the recipient a pull-down list of transfers to accept.
3. The only time that the authorization key is visible to the donor is in the response from the creation of the transfer; after creation, it is impossible for even the donor to recover it. Since the donor must capture the transfer ID and authorization key in order to send it to the recipient, an extra form was created to present this information to the donor immediately after the transfer has been created.

The option to create Block Storage (cinder) volume transfers has been added to the 'Volumes' tab in the OpenStack dashboard. Volume transfers move ownership from one project to another. A donor creates a volume transfer, captures the resulting transfer ID and secret authentication key, and passes that information out of band to the recipient (such as by email or text message). The recipient accepts the transfer, supplying the transfer ID and authentication key. The ownership of the volume is then transferred from the donor to the recipient, and the volume is no longer visible to the donor.

Note the following limitations of the Block Storage API for volume transfers and their impact on the UI design:
1. When creating a volume transfer, you cannot specify who the intended recipient will be, and anyone with the transfer ID and authentication key can claim the volume. Therefore, the dashboard UI does not prompt for a recipient.
2. Current volume transfers are only visible to the donor; users in other projects are unable to view these transfers. So, the UI does not include a project table to view and accept volume transfers, since the current transfers are not visible. Instead, the transfer information is added to the volume details, which are visible by the donor, and the volume state clearly reflects that a transfer has been created. The UI also cannot present to the recipient a pull-down list of transfers to accept.
3. The only time that the authorization key is visible to the donor is in the response from the creation of the transfer; after creation, it is impossible for even the donor to recover it. Since the donor must capture the transfer ID and authorization key in order to send it to the recipient, an extra form was created to present this information to the donor immediately after the transfer has been created.

Heat now supports user hooks, which pause execution of stack operations at specified points to allow the user to insert their own actions into Heat's workflow. Hooks are attached to resources in the stack's environment file. Currently supported hook types are 'pre-create' and 'pre-update'.

Heat now supports user hooks, which pause execution of stack operations at specified points to allow the user to insert their own actions into Heat's workflow. Hooks are attached to resources in the stack's environment file. Currently supported hook types are 'pre-create' and 'pre-update'.

The Identity Service (keystone) now allows for re-delegation of trusts. This allows a trustee with a trust token to create another trust to delegate their roles to others. In addition, a counter enumerates the number of times a trust can be re-delegated.
This feature allows a trustee to re-delegate the roles contained in its trust token to another trustee.  The user creating the initial trust can control if a trust can be re-delegated when this is necessary.
Consequently, trusts can now be re-delegated if the original trust allows it.

The Identity Service (keystone) now allows for re-delegation of trusts. This allows a trustee with a trust token to create another trust to delegate their roles to others. In addition, a counter enumerates the number of times a trust can be re-delegated.
This feature allows a trustee to re-delegate the roles contained in its trust token to another trustee.  The user creating the initial trust can control if a trust can be re-delegated when this is necessary.
Consequently, trusts can now be re-delegated if the original trust allows it.

OpenStack Dashboard now uses Block Storage (cinder) version 2 as its preferred version.
Now when a Block Storage client is requested, access is given using cinder version 2, if not specified otherwise.

OpenStack Dashboard now uses Block Storage (cinder) version 2 as its preferred version.
Now when a Block Storage client is requested, access is given using cinder version 2, if not specified otherwise.

You can now use the dashboard to view, import, and associate metadata definitions that can be used with various resource types (images, artifacts, volumes, flavors, aggregates, etc).

You can now use the dashboard to view, import, and associate metadata definitions that can be used with various resource types (images, artifacts, volumes, flavors, aggregates, etc).

The Image Service now features improved logging, providing better information to users. In addition, logs have been stripped of any sensitive information, and use the appropriate logging levels for messages. This change is only visible to operators.

The Image Service now features improved logging, providing better information to users. In addition, logs have been stripped of any sensitive information, and use the appropriate logging levels for messages. This change is only visible to operators.

Identity Service (keystone) now allows for unscoped tokens to be explicitly requested.
This feature was added after users who had a default project assigned were previously unable to retrieve unscoped tokens; if one of these users requested a token without defining a scope, it would be automatically scoped to the default project.
As a result of this update, unscoped tokens can now be issued to all users, even if they have a default project defined.

Identity Service (keystone) now allows for unscoped tokens to be explicitly requested.
This feature was added after users who had a default project assigned were previously unable to retrieve unscoped tokens; if one of these users requested a token without defining a scope, it would be automatically scoped to the default project.
As a result of this update, unscoped tokens can now be issued to all users, even if they have a default project defined.

In OpenStack Dashboard, the instance detail page now displays the host node. This data is intended to assist when diagnosing issues.

In OpenStack Dashboard, the instance detail page now displays the host node. This data is intended to assist when diagnosing issues.

The OS::Nova::Server resource type now includes a 'console_urls' property. This enables the user to obtain the URL for the server's console (such as a VNC console) from the resource.

The OS::Nova::Server resource type now includes a 'console_urls' property. This enables the user to obtain the URL for the server's console (such as a VNC console) from the resource.

This update adds partial support for Domain Admins to the OpenStack Dashboard. In addition, when using Identity Service (keystone) version 3, a newly-created user does not need to have a primary project specified.

This update adds partial support for Domain Admins to the OpenStack Dashboard. In addition, when using Identity Service (keystone) version 3, a newly-created user does not need to have a primary project specified.

With this enhancement, parameters CONFIG_CONTROLLER_HOST, CONFIG_COMPUTE_HOSTS, CONFIG_NETWORK_HOSTS support the use of hostname values along with the IP address values.

With this enhancement, parameters CONFIG_CONTROLLER_HOST, CONFIG_COMPUTE_HOSTS, CONFIG_NETWORK_HOSTS support the use of hostname values along with the IP address values.

This update adds extended volume manage and unmanage support for NetApp Cmode and 7mode iSCSI drivers. This provides new functionality when using these drivers.

This update adds extended volume manage and unmanage support for NetApp Cmode and 7mode iSCSI drivers. This provides new functionality when using these drivers.

With this update, a new feature implements support to manage/unmanage volumes for the NetApp e-series driver. You can now use the '--source-name' parameter as the mandatory input for volumes not under the Block Storage management.

With this update, a new feature implements support to manage/unmanage volumes for the NetApp e-series driver. You can now use the '--source-name' parameter as the mandatory input for volumes not under the Block Storage management.

When querying a resource in the Orchestration API, a user can now request the value of one or more of the resource's attributes be included in the output. This can aid debugging, as it allows the user to retrieve data from any resource at any time without having to modify the stack's template to include that data in the outputs section.

When querying a resource in the Orchestration API, a user can now request the value of one or more of the resource's attributes be included in the output. This can aid debugging, as it allows the user to retrieve data from any resource at any time without having to modify the stack's template to include that data in the outputs section.

The OS::Cinder::Volume resource type now includes a 'scheduler_hints' property. This allows scheduler hints to be passed to the Block Storage service when creating a volume, and requires v2 of the Block Storage API.

The OS::Cinder::Volume resource type now includes a 'scheduler_hints' property. This allows scheduler hints to be passed to the Block Storage service when creating a volume, and requires v2 of the Block Storage API.

You can now disable and enable compute hosts through the dashboard. This capability is available through the 'Actions' column of every compute host in 'Admin > Hypervisors > Compute Host'.

Disabling a compute host prevents the scheduler from launching instances using that host.

You can now disable and enable compute hosts through the dashboard. This capability is available through the 'Actions' column of every compute host in 'Admin > Hypervisors > Compute Host'.

Disabling a compute host prevents the scheduler from launching instances using that host.

The heat-manage command now includes a subcommand "heat-manage service-list". This subcommand displays information about active "heat-engine" processes, where they are running, and their current status.

The heat-manage command now includes a subcommand "heat-manage service-list". This subcommand displays information about active "heat-engine" processes, where they are running, and their current status.

This enhancement adds namenode high availability as a supported option in the HDP 2.0.6 plugin. 
Users can signal that they require a cluster to be generated in HA mode, by passing a cluster with a quorum of zookeeper servers and journalnodes, and at least 2 namenodes. For example:
"cluster_configs": {
   "HDFSHA": {
      "hdfs.nnha": true
   }
}

This enhancement adds namenode high availability as a supported option in the HDP 2.0.6 plugin. 
Users can signal that they require a cluster to be generated in HA mode, by passing a cluster with a quorum of zookeeper servers and journalnodes, and at least 2 namenodes. For example:
"cluster_configs": {
   "HDFSHA": {
      "hdfs.nnha": true
   }
}

The OS::Neutron::Port resource type now supports a 'binding:vnic_type' property. This property enables users with the appropriate permissions to specify the VNIC type of an OpenStack Networking port.

The OS::Neutron::Port resource type now supports a 'binding:vnic_type' property. This property enables users with the appropriate permissions to specify the VNIC type of an OpenStack Networking port.

The 'Manage/Unmanage' option has been added to the 'Volumes' tab of the OpenStack dashboard. 'Manage' takes an existing volume created outside of OpenStack and makes it available. 'Unmanage' removes the visibility of a volume within OpenStack, but does not delete the actual volume.

The 'Manage/Unmanage' option has been added to the 'Volumes' tab of the OpenStack dashboard. 'Manage' takes an existing volume created outside of OpenStack and makes it available. 'Unmanage' removes the visibility of a volume within OpenStack, but does not delete the actual volume.

With this update, it is now possible to dynamically reload the Image service configuration settings by sending a SIGHUP signal to the 'glance-*' process. This signal will ensure the process re-reads the configuration file and load any new configurations. As a result, there is no need to restart the entire Image service to apply the configuration changes.

With this update, it is now possible to dynamically reload the Image service configuration settings by sending a SIGHUP signal to the 'glance-*' process. This signal will ensure the process re-reads the configuration file and load any new configurations. As a result, there is no need to restart the entire Image service to apply the configuration changes.

Bare Metal now supports the management interface of HP ProLiant Services using the iLO client python library. This allows Bare Metal to perform management operations such as retrieving/setting a boot device.

Bare Metal now supports the management interface of HP ProLiant Services using the iLO client python library. This allows Bare Metal to perform management operations such as retrieving/setting a boot device.

With this update, administrators are now able to view the state of High Availability routers on each node, and specifically, where the active instance is hosted. 
Previously, the High Availability router state information was not visible to the administrator; this made maintenance harder, for example, when moving HA router instances from one agent to another, or assessing the impact of putting a node in maintenance mode. 
This new functionality also serves as a sanity test and offers assurance that a router is indeed active on only one node. As a result, administrators may now run the 'neutron l3-agent-list-hosting-router <router_id>' command on a High Availability router to view where the active instance is currently hosted.

With this update, administrators are now able to view the state of High Availability routers on each node, and specifically, where the active instance is hosted. 
Previously, the High Availability router state information was not visible to the administrator; this made maintenance harder, for example, when moving HA router instances from one agent to another, or assessing the impact of putting a node in maintenance mode. 
This new functionality also serves as a sanity test and offers assurance that a router is indeed active on only one node. As a result, administrators may now run the 'neutron l3-agent-list-hosting-router <router_id>' command on a High Availability router to view where the active instance is currently hosted.

The Bare Metal service can now use cloud-init and similar early-initialization tools to insert user data on instances. Previously, doing so would have required setting up a metadata service to perform this function.

With this new update, Bare Metal can insert instance metadata onto local disk upon deployment -- specifically, to a device labeled 'config-2'. Afterwards, you can configure the early-initialization tool to find this device and extract the data from there.

The Bare Metal service can now use cloud-init and similar early-initialization tools to insert user data on instances. Previously, doing so would have required setting up a metadata service to perform this function.

With this new update, Bare Metal can insert instance metadata onto local disk upon deployment -- specifically, to a device labeled 'config-2'. Afterwards, you can configure the early-initialization tool to find this device and extract the data from there.

The Bare Metal service can now deploy nodes using the Secure Boot feature of the UEFI (http://www.uefi.org). Secure Boot helps ensure that nodes boot only trusted software.

With this, the whole boot chain can be verified at boot time. You can then configure nodes to only boot authorized images, thereby enhancing security.

The Bare Metal service can now deploy nodes using the Secure Boot feature of the UEFI (http://www.uefi.org). Secure Boot helps ensure that nodes boot only trusted software.

With this, the whole boot chain can be verified at boot time. You can then configure nodes to only boot authorized images, thereby enhancing security.

Bare Metal instances now feature a new field named 'maintenance_reason', which can be used to indicate why a node is in maintanance mode.

Bare Metal instances now feature a new field named 'maintenance_reason', which can be used to indicate why a node is in maintanance mode.

This package allows users to create HDP 2.0.6 and CDH 5.3.0 images for use in RHEL OpenStack Platform 7.

This package allows users to create HDP 2.0.6 and CDH 5.3.0 images for use in RHEL OpenStack Platform 7.

With this enhancement, the Sahara API now fully supports the HTTPS protocol.

With this enhancement, the Sahara API now fully supports the HTTPS protocol.

With this update, the underlying asynchronous task engine has been changed. It is now based on the taskflow library. While this does not introduce changes to the API or workflow, it adds the following new configuration option:

[taskflow_executor]
engine_mode = serial # or parallel

With this update, the underlying asynchronous task engine has been changed. It is now based on the taskflow library. While this does not introduce changes to the API or workflow, it adds the following new configuration option:

[taskflow_executor]
engine_mode = serial # or parallel

The AWS::AutoScaling::AutoScalingGroup resource type now supports an 'InstanceId' property. This allows the launch configuration for an autoscaling group to be cloned from an existing server instead of an AWS::AutoScaling::LaunchConfiguration resource.

The AWS::AutoScaling::AutoScalingGroup resource type now supports an 'InstanceId' property. This allows the launch configuration for an autoscaling group to be cloned from an existing server instead of an AWS::AutoScaling::LaunchConfiguration resource.

The user interface options available in the dashboard for the OpenStack Orchestration service (heat) have been improved. For example, users can now check, suspend, resume, and preview stacks.

The user interface options available in the dashboard for the OpenStack Orchestration service (heat) have been improved. For example, users can now check, suspend, resume, and preview stacks.

This update adds NFS back-ends for the cinder-backup service. This now allows back up of volumes to an NFS storage back end.

This update adds NFS back-ends for the cinder-backup service. This now allows back up of volumes to an NFS storage back end.

OpenStack Networking deployments with distributed routers are now able to allow tenants to create their own networks with VLAN segmentation.
Previously, distributed routers only supported tunnel networks, which may have hindered adoption as many deployments prefer to use VLAN tenant networks.
As a result of this update, distributed routers are now able to service tunnel networks as well as VLAN networks.

OpenStack Networking deployments with distributed routers are now able to allow tenants to create their own networks with VLAN segmentation.
Previously, distributed routers only supported tunnel networks, which may have hindered adoption as many deployments prefer to use VLAN tenant networks.
As a result of this update, distributed routers are now able to service tunnel networks as well as VLAN networks.

This update adds functionality to 'cinder-manage db' to safely purge old "deleted" data from the Cinder database. This reduces database space usage and improves database performance.

This update adds functionality to 'cinder-manage db' to safely purge old "deleted" data from the Cinder database. This reduces database space usage and improves database performance.

The AWS::AutoScaling::LaunchConfiguration resource type now supports an 'InstanceId' property. This allows the launch configuration for an autoscaling group to be cloned from an existing server.

The AWS::AutoScaling::LaunchConfiguration resource type now supports an 'InstanceId' property. This allows the launch configuration for an autoscaling group to be cloned from an existing server.

The results displayed in tables for the Data Processing service can now be filtered to allow the user to see only those results that are relevant.

The results displayed in tables for the Data Processing service can now be filtered to allow the user to see only those results that are relevant.

You can now flag a volume as 'Bootable' through the dashboard.

You can now flag a volume as 'Bootable' through the dashboard.

Sahara objects can now be queried by any field name. This is done using the GET parameters that match the API field names, as seen on list methods.

Sahara objects can now be queried by any field name. This is done using the GET parameters that match the API field names, as seen on list methods.

Previously, the glance-manage utility was configured using 'glance-api.conf' or 'glance-registry.conf'. This release features a new configuration file named 'glance-manage.conf', which can be used to configure glance-manage. You can still use 'glance-api.conf' and 'glance-registry.conf' to configure glance-manage, but any 'glance-manage.conf' settings will take precedence.

Previously, the glance-manage utility was configured using 'glance-api.conf' or 'glance-registry.conf'. This release features a new configuration file named 'glance-manage.conf', which can be used to configure glance-manage. You can still use 'glance-api.conf' and 'glance-registry.conf' to configure glance-manage, but any 'glance-manage.conf' settings will take precedence.

The Bare Metal service now supports Fujitsu iRMC (integrated Remote Management Controller) hardware. With this, Bare Metal can now manage the power state of such machines.

The Bare Metal service now supports Fujitsu iRMC (integrated Remote Management Controller) hardware. With this, Bare Metal can now manage the power state of such machines.

With this update, Identity Service (keystone), is now able to construct a hierarchy of projects by specifying a 'parent_id' within a project resource.
Previously, the Identity service only allowed for a flat project model; a project hierarchy allows for more flexible project structures, which can be used to mimic organizational structures.
As a result, Projects can now define a parent project, allowing project hierarchies to be constructed.

With this update, Identity Service (keystone), is now able to construct a hierarchy of projects by specifying a 'parent_id' within a project resource.
Previously, the Identity service only allowed for a flat project model; a project hierarchy allows for more flexible project structures, which can be used to mimic organizational structures.
As a result, Projects can now define a parent project, allowing project hierarchies to be constructed.

The OpenStack dashboard can now use a custom theme. A new setting, 'CUSTOM_THEME_PATH' was added to /etc/openstack_dashboard/local_settings file. The theme folder should contain one _variables.scss file and one _styles.scss file. The _variables.scss file contains all the bootstrap and Horizon-specific variables that are used to style the graphical user interface, and the _styles.scss file contains extra styling.

The OpenStack dashboard can now use a custom theme. A new setting, 'CUSTOM_THEME_PATH' was added to /etc/openstack_dashboard/local_settings file. The theme folder should contain one _variables.scss file and one _styles.scss file. The _variables.scss file contains all the bootstrap and Horizon-specific variables that are used to style the graphical user interface, and the _styles.scss file contains extra styling.

Previously, Image service's 'swift' store implementation stored all images on a single container. While this worked well, it created a performance bottleneck in large scale deployments.

With this update, it is now possible to use several Object Storage containers as storage for the 'glance' images. In order to use this feature, you need to set 'swift_store_multiple_containers_seed' to a value bigger than '0'. You can disable using multiple containers by enabling the 'swift_uer_multi_tenant' parameter, as these containers are split on a per-tenant basis.

Previously, Image service's 'swift' store implementation stored all images on a single container. While this worked well, it created a performance bottleneck in large scale deployments.

With this update, it is now possible to use several Object Storage containers as storage for the 'glance' images. In order to use this feature, you need to set 'swift_store_multiple_containers_seed' to a value bigger than '0'. You can disable using multiple containers by enabling the 'swift_uer_multi_tenant' parameter, as these containers are split on a per-tenant basis.

SRIOV can now be configured in the OpenStack dashboard. Options include exposing further information on the 'Port Details' tab, and allowing port type selection during port creation and update.

SRIOV can now be configured in the OpenStack dashboard. Options include exposing further information on the 'Port Details' tab, and allowing port type selection during port creation and update.

This enhancement allows you to view encryption metadata for encrypted volumes in OpenStack Dashboard (horizon). A function to display encryption metadata was added, and allows the user to click on the "Yes" in the Encrypted column, and be taken to a page where the encryption metadata is visible.

This enhancement allows you to view encryption metadata for encrypted volumes in OpenStack Dashboard (horizon). A function to display encryption metadata was added, and allows the user to click on the "Yes" in the Encrypted column, and be taken to a page where the encryption metadata is visible.

The glance_store library now supports more storage capabilities. As such, you now have more granular control over what operations are allowed in a specific store. This release features the following capabilities:

 - READ_ACCESS: Generic read access 
 - WRITE_ACCESS: Generic write access
 - RW_ACCESS  : READ_ACCESS and WRITE_ACCESS
 - READ_OFFSET: Read all bits from a offset (Included in READ_ACCESS)  
 - WRITE_OFFSET: Write all bits to a offset  (Included in WRITE_ACCESS) 
 - RW_OFFSET  : READ_OFFSET and WRITE_OFFSET
 - READ_CHUNK : Read required length of bits (Included in READ_ACCESS)  
 - WRITE_CHUNK: Write required length of bits  (Included in WRITE_ACCESS) 
 - RW_CHUNK: READ_CHUNK and WRITE_CHUNK  
 - READ_RANDOM: READ_OFFSET and READ_CHUNK  
 - WRITE_RANDOM: WRITE_OFFSET and WRITE_CHUNK
 - RW_RANDOM: RW_OFFSET and RW_CHUNK  
 - DRIVER_REUSABLE: driver is stateless and its instance can be reused safely

The glance_store library now supports more storage capabilities. As such, you now have more granular control over what operations are allowed in a specific store. This release features the following capabilities:

 - READ_ACCESS: Generic read access 
 - WRITE_ACCESS: Generic write access
 - RW_ACCESS  : READ_ACCESS and WRITE_ACCESS
 - READ_OFFSET: Read all bits from a offset (Included in READ_ACCESS)  
 - WRITE_OFFSET: Write all bits to a offset  (Included in WRITE_ACCESS) 
 - RW_OFFSET  : READ_OFFSET and WRITE_OFFSET
 - READ_CHUNK : Read required length of bits (Included in READ_ACCESS)  
 - WRITE_CHUNK: Write required length of bits  (Included in WRITE_ACCESS) 
 - RW_CHUNK: READ_CHUNK and WRITE_CHUNK  
 - READ_RANDOM: READ_OFFSET and READ_CHUNK  
 - WRITE_RANDOM: WRITE_OFFSET and WRITE_CHUNK
 - RW_RANDOM: RW_OFFSET and RW_CHUNK  
 - DRIVER_REUSABLE: driver is stateless and its instance can be reused safely

With this update, a completely new API that adds search capabilities for Image service and improves the performance for listing and search operations, especially on interactions with the UI is now available.

The search API allows users to execute a search query and get back search hits that match the query. The query can either by provided using a simple query string as a parameter, or using a request body. All the search APIs can be applied across multiple types within an index, and across multiple indices with support for multi index syntax.

Note: This enhancement will be removed from the Image service during the RHEL OpenStack Plaform 8 (Liberty) release.

With this update, a completely new API that adds search capabilities for Image service and improves the performance for listing and search operations, especially on interactions with the UI is now available.

The search API allows users to execute a search query and get back search hits that match the query. The query can either by provided using a simple query string as a parameter, or using a request body. All the search APIs can be applied across multiple types within an index, and across multiple indices with support for multi index syntax.

Note: This enhancement will be removed from the Image service during the RHEL OpenStack Plaform 8 (Liberty) release.

This feature adds IPv6 support to Packstack, allowing Packstack to use IPv6 address as values in networking-related parameters such as CONFIG_CONTROLLER_HOST, CONFIG_COMPUTE_HOSTS, and CONFIG_NETWORK_HOSTS.

This feature adds IPv6 support to Packstack, allowing Packstack to use IPv6 address as values in networking-related parameters such as CONFIG_CONTROLLER_HOST, CONFIG_COMPUTE_HOSTS, and CONFIG_NETWORK_HOSTS.

This enhancement adds a CLI that allows configuration of the default cluster templates for each major plugin. The provision of default templates is expected to speed and facilitate end-user adoption of Sahara.
As a result of this update, administrators can now add shared default templates for adaptation and direct usage by customers.

This enhancement adds a CLI that allows configuration of the default cluster templates for each major plugin. The provision of default templates is expected to speed and facilitate end-user adoption of Sahara.
As a result of this update, administrators can now add shared default templates for adaptation and direct usage by customers.

Integration tests for Sahara have been refactored from more brittle pure python tests to allow easy, YAML-based configuration to define "scenarios".

Integration tests for Sahara have been refactored from more brittle pure python tests to allow easy, YAML-based configuration to define "scenarios".

Previously, the cm_api library was not packaged by Cloudera for any Linux distribution. The previous CDH plug-in depended on this package, so CDH could not be enabled as a default plug-in prior to this release. Now, a subset of the cm_api library has been added to Sahara's codebase, and CDH is functional and enabled by default.

Previously, the cm_api library was not packaged by Cloudera for any Linux distribution. The previous CDH plug-in depended on this package, so CDH could not be enabled as a default plug-in prior to this release. Now, a subset of the cm_api library has been added to Sahara's codebase, and CDH is functional and enabled by default.

The Identity service now allows unscoped federation tokens to be used to obtain a scoped token using the 'token' authentication method.

When using the Identity service's federation extension, an unscoped federation token is returned as a result of the initial authentication. This is then exchanged for a scoped token. An unscoped federation token previously had to use the 'saml2' or 'mapped' authentication to obtain a scoped token. This is inconsistent with the method used to exchanging a regular unscoped token for a scoped token, which uses the 'token' method.

Exchanging an unscoped federation token for a scoped token now uses the 'token' authentication method, which is consistent with the regular unscoped token behavior.

The Identity service now allows unscoped federation tokens to be used to obtain a scoped token using the 'token' authentication method.

When using the Identity service's federation extension, an unscoped federation token is returned as a result of the initial authentication. This is then exchanged for a scoped token. An unscoped federation token previously had to use the 'saml2' or 'mapped' authentication to obtain a scoped token. This is inconsistent with the method used to exchanging a regular unscoped token for a scoped token, which uses the 'token' method.

Exchanging an unscoped federation token for a scoped token now uses the 'token' authentication method, which is consistent with the regular unscoped token behavior.

The Identity service now allows restriction of re-scoping tokens to only allow unscoped changes to be exchanged for scoped tokens.

The Identity service allows for an existing token to be used to obtain a new token via the 'token' authentication method.  Previously, a user with a valid token scoped for a project could use that token to obtain another token for a different project that they were authorized for.  This allowed for anyone possessing a user's token to have access to any project the user has access to, as opposed to only having access to the project that the token is scoped for.  To improve the security properties of scoped tokens, it was desirable to not allow this.
 
A new 'allow_rescope_scoped_token' configuration option is available to allow token rescoping to be retricted. Rescoping of tokens is now only allowed by using an unscoped token to authenticate when this option is enabled.

The Identity service now allows restriction of re-scoping tokens to only allow unscoped changes to be exchanged for scoped tokens.

The Identity service allows for an existing token to be used to obtain a new token via the 'token' authentication method.  Previously, a user with a valid token scoped for a project could use that token to obtain another token for a different project that they were authorized for.  This allowed for anyone possessing a user's token to have access to any project the user has access to, as opposed to only having access to the project that the token is scoped for.  To improve the security properties of scoped tokens, it was desirable to not allow this.
 
A new 'allow_rescope_scoped_token' configuration option is available to allow token rescoping to be retricted. Rescoping of tokens is now only allowed by using an unscoped token to authenticate when this option is enabled.

The dashboard now provides wizards for creating and configuring the necessary components of the OpenStack Data Processing feature. These wizards are useful for guiding users through the process of cluster creation and job execution. To use these wizards, go to 'Project > Data Processing > Guides'.

The dashboard now provides wizards for creating and configuring the necessary components of the OpenStack Data Processing feature. These wizards are useful for guiding users through the process of cluster creation and job execution. To use these wizards, go to 'Project > Data Processing > Guides'.

This enhancement adds ceilometer IPMI meters to OpenStack Dashboard.
Six ipmi meters have been exported from ceilometer; the methods 'list_ipmi' and '_get_ipmi_meters_info' are used to retrieve the meter data.

This enhancement adds ceilometer IPMI meters to OpenStack Dashboard.
Six ipmi meters have been exported from ceilometer; the methods 'list_ipmi' and '_get_ipmi_meters_info' are used to retrieve the meter data.

Previously, every call to policy.enforce passed an empty dictionary as the target. This prevented operators from using tenant specific restrictions in their policy.json files since the target would always be an empty dictionary. If you tried to restrict some actions so an image owner (users with the correct tenant id) could perform actions, the check categorically failed because the target is okay is an empty dictionary.

With this update, you can pass the ImageTarget instance wrapping an Image to the enforcer so these rules can be used and properly enforced. You can now properly grant access to the image owner(s) based on tenant (e.g., owner:%(tenant)). Without this fix, the only check that actually works in Image service is a RoleCheck (e.g., role:admin).

Previously, every call to policy.enforce passed an empty dictionary as the target. This prevented operators from using tenant specific restrictions in their policy.json files since the target would always be an empty dictionary. If you tried to restrict some actions so an image owner (users with the correct tenant id) could perform actions, the check categorically failed because the target is okay is an empty dictionary.

With this update, you can pass the ImageTarget instance wrapping an Image to the enforcer so these rules can be used and properly enforced. You can now properly grant access to the image owner(s) based on tenant (e.g., owner:%(tenant)). Without this fix, the only check that actually works in Image service is a RoleCheck (e.g., role:admin).

You can now view details about Orchestration service hosts through the dashboard. To do so, go to 'Admin > System > System Information > Orchestration Services'. This page is only available if the Orchestration service is deployed.

You can now view details about Orchestration service hosts through the dashboard. To do so, go to 'Admin > System > System Information > Orchestration Services'. This page is only available if the Orchestration service is deployed.

Previously, many of the processes in cluster creation polled infinitely. Now, timeouts have been added for many stages of cluster creation and manipulation, and users are shown appropriate error messages when cluster operations have taken longer than is reasonable.

Previously, many of the processes in cluster creation polled infinitely. Now, timeouts have been added for many stages of cluster creation and manipulation, and users are shown appropriate error messages when cluster operations have taken longer than is reasonable.

Support has been added for intelligent NUMA node placement for guests that have been assigned a host PCI device. PCI I/O devices, such as  Network Interface Cards (NICs), can be more closely associated with one processor than another. This is important because there are different memory performance and latency characteristics when accessing memory directly attached to one processor than when accessing memory directly attached to another processor in the same server. With this update, Openstack guest placement can be optimized by ensuring that a guest bound to a PCI device is scheduled to run on a NUMA node that is associated with the guest's pCPU and memory allocation. For example, if a guest's resource requirements fit in a single NUMA node, all guest resources will now be associated with the same NUMA node.

Support has been added for intelligent NUMA node placement for guests that have been assigned a host PCI device. PCI I/O devices, such as  Network Interface Cards (NICs), can be more closely associated with one processor than another. This is important because there are different memory performance and latency characteristics when accessing memory directly attached to one processor than when accessing memory directly attached to another processor in the same server. With this update, Openstack guest placement can be optimized by ensuring that a guest bound to a PCI device is scheduled to run on a NUMA node that is associated with the guest's pCPU and memory allocation. For example, if a guest's resource requirements fit in a single NUMA node, all guest resources will now be associated with the same NUMA node.

A new endpoint has been added to Sahara that allows queries of the available job types per plug-in and version that the Sahara installation supports. This information is useful both for UI presentation and filtering, and for CLI and REST API users.

A new endpoint has been added to Sahara that allows queries of the available job types per plug-in and version that the Sahara installation supports. This information is useful both for UI presentation and filtering, and for CLI and REST API users.

The Identity service now has an experimental support for a new token format called 'fernet'.

The token formats currently supported by the Identity service require issued tokens to be persisted in a database table. This table can grow quite large, which requires proper tuning and a flush job to keep the Identity service performing well. The new 'fernet' token format is designed to allow the token database table to be eliminated, avoiding the problem of this table becoming a scalability limitation. The 'fernet' token format is now available as an experimental feature.

The Identity service now has an experimental support for a new token format called 'fernet'.

The token formats currently supported by the Identity service require issued tokens to be persisted in a database table. This table can grow quite large, which requires proper tuning and a flush job to keep the Identity service performing well. The new 'fernet' token format is designed to allow the token database table to be eliminated, avoiding the problem of this table becoming a scalability limitation. The 'fernet' token format is now available as an experimental feature.

All Ironic drivers now support deployment via IPA ramdisk. IPA is written in Python, supports more features than the BASH ramdisk, and runs as a service. For these reasons, nodes deployed through IPA are generally easier to deploy, debug, and manage.

All Ironic drivers now support deployment via IPA ramdisk. IPA is written in Python, supports more features than the BASH ramdisk, and runs as a service. For these reasons, nodes deployed through IPA are generally easier to deploy, debug, and manage.

With this update, it is now possible to filter the list operations by more than one filter option and in multiple directions. For example:

  /images?sort=status:asc,name:asc,created_at:desc

With the above, a list of images will be returned and they will be sorted by status, name, and creation date with the following directions respectively: ascending, ascending, and descending.

With this update, it is now possible to filter the list operations by more than one filter option and in multiple directions. For example:

  /images?sort=status:asc,name:asc,created_at:desc

With the above, a list of images will be returned and they will be sorted by status, name, and creation date with the following directions respectively: ascending, ascending, and descending.

With this change, it is now possible to filter the list operations by more than one filter option and in multiple directions. For example:

  /images?sort=status:asc,name:asc,created_at:desc

With the above, a list of images will be returned and they will be sorted by status, name, and creation date with the following directions respectively: ascending, ascending, and descending.

With this change, it is now possible to filter the list operations by more than one filter option and in multiple directions. For example:

  /images?sort=status:asc,name:asc,created_at:desc

With the above, a list of images will be returned and they will be sorted by status, name, and creation date with the following directions respectively: ascending, ascending, and descending.

This update adds the ability to assign a user group as the instance owner, which allows other members of the same group to control the instance when its creator is not reachable.

This update adds the ability to assign a user group as the instance owner, which allows other members of the same group to control the instance when its creator is not reachable.

Imbalance in tiers in Swift was previously addressed by weights. However, no matter what the numerical ratio of weight is set, at a certain point there are not enough devices and replicas remaining in lower weight tiers to balance out the crowding at the higher weight tier. At this moment, the tier becomes underutilized, while an administrator may need to force more than one replica into tier to achieve utilization. The ratio of more-than-1 partition is the overload parameter.

This update permits administrators to store more than one replica in a tier in case of severely unbalanced clusters. As a result, it is now possible so sacrifice data durability in order to achieve better utilization, which in some cases is required for availability. For example, a cluster will fail to store new data if low-weight tiers overflow and quorum fails.

Imbalance in tiers in Swift was previously addressed by weights. However, no matter what the numerical ratio of weight is set, at a certain point there are not enough devices and replicas remaining in lower weight tiers to balance out the crowding at the higher weight tier. At this moment, the tier becomes underutilized, while an administrator may need to force more than one replica into tier to achieve utilization. The ratio of more-than-1 partition is the overload parameter.

This update permits administrators to store more than one replica in a tier in case of severely unbalanced clusters. As a result, it is now possible so sacrifice data durability in order to achieve better utilization, which in some cases is required for availability. For example, a cluster will fail to store new data if low-weight tiers overflow and quorum fails.

Previously, the GUI did not allow a user to create or upload images.

This new feature adds the following changes to the horizon and the tuskar-ui packages. To horizon, it adds the Kernel and Ramdisk fields to the create image form in horizon, which enables a user to associate a kernel and a ramdisk to a glance image during image creation. In the tuskar-ui, it exposes horizon's create image form (with the newly added capability to set kernel and ramdisk) in the tuskar-ui. On the images page, there should now be a "create image" button which allows the user to create an image. As a result, GUI now has the ability to create images.

Previously, the GUI did not allow a user to create or upload images.

This new feature adds the following changes to the horizon and the tuskar-ui packages. To horizon, it adds the Kernel and Ramdisk fields to the create image form in horizon, which enables a user to associate a kernel and a ramdisk to a glance image during image creation. In the tuskar-ui, it exposes horizon's create image form (with the newly added capability to set kernel and ramdisk) in the tuskar-ui. On the images page, there should now be a "create image" button which allows the user to create an image. As a result, GUI now has the ability to create images.

Previously, when using huge pages, the back-end memory for a guest was configured as private. Consequently, the vhostuser VIF back end was designed to allow an external process to provide the QEMU network driver functionality. For some use cases of vhostuser, this required that the external process be able to access the QEMU guest's memory pages directly. This is not possible when the huge pages are mapped with MAP_PRIVATE; they must use MAP_SHARED instead. With this update, when a guest is configured to use huge pages backed memory, mappings are be marked as shared. As a result, the external process to provide QEMU network is now able to access to guest's memory pages.

Previously, when using huge pages, the back-end memory for a guest was configured as private. Consequently, the vhostuser VIF back end was designed to allow an external process to provide the QEMU network driver functionality. For some use cases of vhostuser, this required that the external process be able to access the QEMU guest's memory pages directly. This is not possible when the huge pages are mapped with MAP_PRIVATE; they must use MAP_SHARED instead. With this update, when a guest is configured to use huge pages backed memory, mappings are be marked as shared. As a result, the external process to provide QEMU network is now able to access to guest's memory pages.

This enhancement adds support for the Cisco N1kV plugin. This includes environment configuration in the TripleO Heat Template collection.

This enhancement adds support for the Cisco N1kV plugin. This includes environment configuration in the TripleO Heat Template collection.

This enhancement adds support for the Nexus-9k ML2 Neutron plugin. This includes environment configuration in the TripleO Heat Template collection as well as configuration in the Openstack Puppet Module collection.

This enhancement adds support for the Nexus-9k ML2 Neutron plugin. This includes environment configuration in the TripleO Heat Template collection as well as configuration in the Openstack Puppet Module collection.

This enhancement adds support for the Cisco UCSM Neutron ML2 plugin. This includes environment configuration in the TripleO Heat Template collection as well as configuration in the Openstack Puppet Module collection.

This enhancement adds support for the Cisco UCSM Neutron ML2 plugin. This includes environment configuration in the TripleO Heat Template collection as well as configuration in the Openstack Puppet Module collection.

Bare Metal Provisioning (Ironic) now supports a driver that manages Cisco UCS servers. Using the new driver with Cisco UCS servers allows for better support for more advanced features.

Bare Metal Provisioning (Ironic) now supports a driver that manages Cisco UCS servers. Using the new driver with Cisco UCS servers allows for better support for more advanced features.

This fix adds support for Cisco UCS machines to Ironic's power management control in the director. Cisco UCS nodes are manageable using the IPMI protocol, but some customers might want to use the specific Cisco UCS driver to manage more advanced features. Now the director supports power management for Cisco UCS machines.

This fix adds support for Cisco UCS machines to Ironic's power management control in the director. Cisco UCS nodes are manageable using the IPMI protocol, but some customers might want to use the specific Cisco UCS driver to manage more advanced features. Now the director supports power management for Cisco UCS machines.

RBD snapshots and cloning are now used for Ceph-based ephemeral disk snapshots. With this update, data is manipulated within the Ceph server, rather than transferred across nodes, resulting in better snapshotting performance for Ceph.

RBD snapshots and cloning are now used for Ceph-based ephemeral disk snapshots. With this update, data is manipulated within the Ceph server, rather than transferred across nodes, resulting in better snapshotting performance for Ceph.

The nexus1000v (n1kv) Puppet class has been added.

The nexus1000v (n1kv) Puppet class has been added.

Users can now set the maintenance mode and provision state of Bare Metal Provisioning (Ironic) nodes using 'openstackclient' commands. Previously, Ironic used a mix of 'python-ironicclient' and 'openstackclient' commands. This enhancement provides a more unified interface to the user. The new commands are available as part of the 'openstack baremetal' command-line interface.

Users can now set the maintenance mode and provision state of Bare Metal Provisioning (Ironic) nodes using 'openstackclient' commands. Previously, Ironic used a mix of 'python-ironicclient' and 'openstackclient' commands. This enhancement provides a more unified interface to the user. The new commands are available as part of the 'openstack baremetal' command-line interface.

This enhancement adds support for the Cisco N1kV VEM module. This includes environment configuration in the TripleO Heat Template collection.

This enhancement adds support for the Cisco N1kV VEM module. This includes environment configuration in the TripleO Heat Template collection.

This enhancement adds Linux bonding configuration through the director. The director used only OVS and VLAN bonding previously. Linux bonding provides increased performance and additional bonding modes.

This enhancement adds Linux bonding configuration through the director. The director used only OVS and VLAN bonding previously. Linux bonding provides increased performance and additional bonding modes.

The kafka-python library is now included in this release (provided by the python-kafka package). This library provides support for Apache Kafka; this, in turn, allows the Telemetry service to dispatch events and samples with the Kafka publisher.

The kafka-python library is now included in this release (provided by the python-kafka package). This library provides support for Apache Kafka; this, in turn, allows the Telemetry service to dispatch events and samples with the Kafka publisher.

This enhancement increases the levels of configuration for the Overcloud's Neutron service. Customers can now configure values for core_plugin, type_drivers, and service_plugins through the director.

This enhancement increases the levels of configuration for the Overcloud's Neutron service. Customers can now configure values for core_plugin, type_drivers, and service_plugins through the director.

The enhancement adds the 'python-networking-cisco' package. This enables support for multiple Cisco plugins and drivers in OpenStack Networking (neutron).

The enhancement adds the 'python-networking-cisco' package. This enables support for multiple Cisco plugins and drivers in OpenStack Networking (neutron).

This feature allows the S3 driver to be configured to pass through a proxy. The boto library already supported this capability, but it was not exposed through the glance_store API.

The following configuration options have been added and are turned off by default. They must be configured for the S3 driver to use the proxy:

* s3_store_enable_proxy
* s3_store_proxy_host
* s3_store_proxy_port
* s3_store_proxy_user
* s3_store_proxy_password

This feature allows the S3 driver to be configured to pass through a proxy. The boto library already supported this capability, but it was not exposed through the glance_store API.

The following configuration options have been added and are turned off by default. They must be configured for the S3 driver to use the proxy:

* s3_store_enable_proxy
* s3_store_proxy_host
* s3_store_proxy_port
* s3_store_proxy_user
* s3_store_proxy_password

On a PATCH update (using the "-x" flag in the 'heat stack-update' command), the existing environment is now retained unless explicitly overridden. This is because the Orchestration service now re-uses other parts of the environment, not just the parameters that were passed previously and not overriden.

This feature was added because in the most common stack update cases, users prefer to maintain the current environment (including resource mappings and the like). This will also prevent any unintended changes in complex deployments whenever users forget to include the required environment files at stack creation time.

On a PATCH update (using the "-x" flag in the 'heat stack-update' command), the existing environment is now retained unless explicitly overridden. This is because the Orchestration service now re-uses other parts of the environment, not just the parameters that were passed previously and not overriden.

This feature was added because in the most common stack update cases, users prefer to maintain the current environment (including resource mappings and the like). This will also prevent any unintended changes in complex deployments whenever users forget to include the required environment files at stack creation time.

This enhancement adds support for the fake_pxe Ironic driver for registering machines without power management to the director. Use the fake_pxe driver as a fallback driver for machines without a power management system. Perform all power operations manually when using this driver.

This enhancement adds support for the fake_pxe Ironic driver for registering machines without power management to the director. Use the fake_pxe driver as a fallback driver for machines without a power management system. Perform all power operations manually when using this driver.

This enhancement upgrades the Overcloud image content to Red Hat Enterprise Linux 7.2 content, including the latest version of Pacemaker. The previous Overcloud image used Red Hat Enterprise Linux 7.1 content.

This enhancement upgrades the Overcloud image content to Red Hat Enterprise Linux 7.2 content, including the latest version of Pacemaker. The previous Overcloud image used Red Hat Enterprise Linux 7.1 content.

This enhancement adds support for Fujitsu's iRMC Ironic driver in the director. The director now controls the power management of iRMC nodes in the Overcloud.

This enhancement adds support for Fujitsu's iRMC Ironic driver in the director. The director now controls the power management of iRMC nodes in the Overcloud.

The Overcloud image is now multipath aware. This helps users aiming to deploy on nodes using a mutltipathed boot LUN. The operating system root is now mounted properly (e.g. /dev/mpatha).

The Overcloud image is now multipath aware. This helps users aiming to deploy on nodes using a mutltipathed boot LUN. The operating system root is now mounted properly (e.g. /dev/mpatha).

This feature allows the reapplication of Puppet manifests on a deployed Overcloud. This ensures the overcloud has the desired configuration or can recover accidentally amended or deleted configuration files.

To have Puppet run again on the Overcloud nodes, omit the "--templates" option but include the following two environments files at the beginning of your deployment:

* /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml
* /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration-resource-registry.yaml

For example:

$ openstack overcloud deploy -e ~/templates/overcloud-resource-registry-puppet.yaml -e ~/templates/extraconfig/pre_deploy/rhel-registration/rhel-registration-resource-registry.yaml [additional arguments from initial deployment]

This feature allows the reapplication of Puppet manifests on a deployed Overcloud. This ensures the overcloud has the desired configuration or can recover accidentally amended or deleted configuration files.

To have Puppet run again on the Overcloud nodes, omit the "--templates" option but include the following two environments files at the beginning of your deployment:

* /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml
* /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration-resource-registry.yaml

For example:

$ openstack overcloud deploy -e ~/templates/overcloud-resource-registry-puppet.yaml -e ~/templates/extraconfig/pre_deploy/rhel-registration/rhel-registration-resource-registry.yaml [additional arguments from initial deployment]

This enhancement adds support for the Nuage on highly available Overcloud environments. This includes Nuage-specific parameters in the director's Heat template collection, and environment files to enable the Nuage backend on Controller and Compute nodes.

This enhancement adds support for the Nuage on highly available Overcloud environments. This includes Nuage-specific parameters in the director's Heat template collection, and environment files to enable the Nuage backend on Controller and Compute nodes.

This enhancement adds support for the Nuage metadata agent on the Overcloud. This includes parameters in the director's Heat template collection for the Nuage metadata agent.

This enhancement adds support for the Nuage metadata agent on the Overcloud. This includes parameters in the director's Heat template collection for the Nuage metadata agent.

This enhancement adds support to register Overcloud nodes to a Red Hat Satellite 5 server. Previous versions allowed registration only to a Red Hat Satellite 6 server. Now the director determines whether to register to a Red Hat Satellite 5 or Red Hat Satellite 6 server when using the '--reg-method satellite' option during Overcloud creation.

This enhancement adds support to register Overcloud nodes to a Red Hat Satellite 5 server. Previous versions allowed registration only to a Red Hat Satellite 6 server. Now the director determines whether to register to a Red Hat Satellite 5 or Red Hat Satellite 6 server when using the '--reg-method satellite' option during Overcloud creation.

This enhancement adds SSL support to the Overcloud's Public API. Users can now configure SSL on the Overcloud using the 'environments/enable-tls.yaml' from the director's Heat template collection. Copy and modify this environment file to suit your SSL requirements. For more information, see " ⁠6.2.7. Enabling SSL/TLS on the Overcloud" in the Director Installation and Usage guide for Red Hat OpenStack Platform 7.3.

This enhancement adds SSL support to the Overcloud's Public API. Users can now configure SSL on the Overcloud using the 'environments/enable-tls.yaml' from the director's Heat template collection. Copy and modify this environment file to suit your SSL requirements. For more information, see " ⁠6.2.7. Enabling SSL/TLS on the Overcloud" in the Director Installation and Usage guide for Red Hat OpenStack Platform 7.3.

With this update, the package python-pytimeparse is rebased to version 1.1.5 for openstack-gnocchi, so that gnocchi-dbsync can work successfully without any ImportErrors.

With this update, the package python-pytimeparse is rebased to version 1.1.5 for openstack-gnocchi, so that gnocchi-dbsync can work successfully without any ImportErrors.

OpenStack Compute includes the concept of Cells, provided by the nova-cells package, for dividing computing resources.

Cells are provided in Red Hat Enterprise Linux OpenStack Platform as a Technology Preview at this time. Fully supported methods for dividing compute resources in Red Hat Enterprise Linux OpenStack Platform include Regions, Availability Zones, and Host Aggregates.

OpenStack Compute includes the concept of Cells, provided by the nova-cells package, for dividing computing resources.

Cells are provided in Red Hat Enterprise Linux OpenStack Platform as a Technology Preview at this time. Fully supported methods for dividing compute resources in Red Hat Enterprise Linux OpenStack Platform include Regions, Availability Zones, and Host Aggregates.

Support for SPICE remote console access was recently added to the Compute (Nova) and Dashboard (Horizon) services. The spice-html5 package required to support SPICE access is however not included in this release. As such SPICE remote console access remains unsupported at this time.

Support for SPICE remote console access was recently added to the Compute (Nova) and Dashboard (Horizon) services. The spice-html5 package required to support SPICE access is however not included in this release. As such SPICE remote console access remains unsupported at this time.

This feature aims to improve the libvirt driver so that it can use large pages for backing the guest RAM allocation. This will improve the performance of guest workloads by increasing TLB cache efficiency. It will ensure that the guest has 100% dedicated RAM that will never be swapped out.

This feature aims to improve the libvirt driver so that it can use large pages for backing the guest RAM allocation. This will improve the performance of guest workloads by increasing TLB cache efficiency. It will ensure that the guest has 100% dedicated RAM that will never be swapped out.

Efficient replication of distributed regions is now possible. Existing replication sends data over unnecessarily. For example, in case of two regions and replication factor of four, a typical spread is to have two replicas per region, assuming uniform weights. If the long-haul link goes down and up, replicators send two copies of every outstanding object across regions. This is not necessary. If only one copy is sent over, replicators of the remote region restore complete redundancy without using the long-haul bandwidth.

This update ensures stable performance during a recovery after an outage in a multi-region cluster. It has no effect inside a one-region datacenter.

Efficient replication of distributed regions is now possible. Existing replication sends data over unnecessarily. For example, in case of two regions and replication factor of four, a typical spread is to have two replicas per region, assuming uniform weights. If the long-haul link goes down and up, replicators send two copies of every outstanding object across regions. This is not necessary. If only one copy is sent over, replicators of the remote region restore complete redundancy without using the long-haul bandwidth.

This update ensures stable performance during a recovery after an outage in a multi-region cluster. It has no effect inside a one-region datacenter.

After fully upgrading to Red Hat Enterprise Linux OpenStack Platform 7 from version 6 (and all nodes are running version 7 code), you should start a background migration of PCI device NUMA node information from the old location to the new location. Version 7 conductor nodes will do this automatically when necessary, but the rest of the idle data needs to be migrated in the background. This is critical to complete before the version 8 release, where support for the old location will be dropped. Use '$ nova-manage db migrate_rhos_6_pci_device_data --max-number X' to perform this transition (where X is the maximum number of devices to be migrated in one run).
Note that this is relevant only for users making use of the PCI pass-through features of Compute.

After fully upgrading to Red Hat Enterprise Linux OpenStack Platform 7 from version 6 (and all nodes are running version 7 code), you should start a background migration of PCI device NUMA node information from the old location to the new location. Version 7 conductor nodes will do this automatically when necessary, but the rest of the idle data needs to be migrated in the background. This is critical to complete before the version 8 release, where support for the old location will be dropped. Use '$ nova-manage db migrate_rhos_6_pci_device_data --max-number X' to perform this transition (where X is the maximum number of devices to be migrated in one run).
Note that this is relevant only for users making use of the PCI pass-through features of Compute.

In Kilo, Neutron services now can rely on so called rootwrap daemon to execute external commands like 'ip' or 'sysctl'. The daemon pre-caches rootwrap filters and drastically improves overall agent performance.

For RHEL-OSP7, rootwrap daemon is enabled by default. If you want to avoid using it and stick to another root privilege separation mechanism like 'sudo', then make sure you also disable the daemon by setting 'root_helper_daemon =' in [agent] section of your neutron.conf file.

In Kilo, Neutron services now can rely on so called rootwrap daemon to execute external commands like 'ip' or 'sysctl'. The daemon pre-caches rootwrap filters and drastically improves overall agent performance.

For RHEL-OSP7, rootwrap daemon is enabled by default. If you want to avoid using it and stick to another root privilege separation mechanism like 'sudo', then make sure you also disable the daemon by setting 'root_helper_daemon =' in [agent] section of your neutron.conf file.

When using static IP's on the ctlpane network, DNS must be configured on the Overcloud nodes. Previously, DHCP provided the configured DNS servers for the Overcloud nodes.

To configure DNS when using static IPs set the new DnsServers parameter and include it in the Heat environment like so:

parameter_defaults:
  DnsServers:
    - <dns server ip address>
    - <dns server ip address 2>

Use IP addresses for the DNS servers to use. You can only specify either one or two DNS servers.

When using static IP's on the ctlpane network, DNS must be configured on the Overcloud nodes. Previously, DHCP provided the configured DNS servers for the Overcloud nodes.

To configure DNS when using static IPs set the new DnsServers parameter and include it in the Heat environment like so:

parameter_defaults:
  DnsServers:
    - <dns server ip address>
    - <dns server ip address 2>

Use IP addresses for the DNS servers to use. You can only specify either one or two DNS servers.

Due to a known issue with the 'python-neutron-fwaas' package, Firewall-as-a-Service (FWaaS) may fail to work. This is a result of the 'python-neutron-fwaas' package missing the database upgrade 'versions' directory.
In addition, upgrading the database schemas between version releases may not function correctly at this time.

Due to a known issue with the 'python-neutron-fwaas' package, Firewall-as-a-Service (FWaaS) may fail to work. This is a result of the 'python-neutron-fwaas' package missing the database upgrade 'versions' directory.
In addition, upgrading the database schemas between version releases may not function correctly at this time.

The Director uses misconfigured HAProxy settings when deploying the Bare Metal and Telemetry services with SSL enabled in the undercloud. This prevents some nodes from registering. 

To work around this, comment out 'option ssl-hello-chk' under the Bare Metal and Telemetry sections in /etc/haproxy/haproxy.cfg after installing the undercloud.

The Director uses misconfigured HAProxy settings when deploying the Bare Metal and Telemetry services with SSL enabled in the undercloud. This prevents some nodes from registering. 

To work around this, comment out 'option ssl-hello-chk' under the Bare Metal and Telemetry sections in /etc/haproxy/haproxy.cfg after installing the undercloud.

The GlusterFS native driver of the File Share Service allows users to create shares of specified sizes. If no Red Hat Gluster volumes of the exact requested size exist, the driver chooses one with the nearest possible size and creates a share on the volume. Whenever this occurs, the resulting share will use the entire volume.

For example, if a user requests a 1GB share and only 2GB, 3GB, and 4GB volumes are available, the driver will choose the 2GB volume as a back end for the share. The driver will also proceed with creating a 2GB share; the user will be able to use and mount the entire 2GB share. 

To work around this, implement File Share quotas for users. Doing so will prevent them from provisioning more file share storage than what they are entitled to.

The GlusterFS native driver of the File Share Service allows users to create shares of specified sizes. If no Red Hat Gluster volumes of the exact requested size exist, the driver chooses one with the nearest possible size and creates a share on the volume. Whenever this occurs, the resulting share will use the entire volume.

For example, if a user requests a 1GB share and only 2GB, 3GB, and 4GB volumes are available, the driver will choose the 2GB volume as a back end for the share. The driver will also proceed with creating a 2GB share; the user will be able to use and mount the entire 2GB share. 

To work around this, implement File Share quotas for users. Doing so will prevent them from provisioning more file share storage than what they are entitled to.

With this update, the default network where the 'KeystoneAdminVip' is placed was changed from 'InternalApi' to 'ctlplane' so that the post-deployment Identity service initialization step could be carried by the Undercloud over the 'ctlplane' network. Relocating the 'KeystoneAdminVip' causes a cascading restart of the services pointing to the old 'KeystoneAdminVip'.

As a workaround to make sure the KeystoneAdminVip remains on the 'InternalApi' network, a customized 'ServiceNetMap' must be provided as deployment parameter when launching an update from the 7.0 release. A sample Orchestration environment file passing a customized 'ServiceNetMap' is as follows:


parameters:
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage

If any additional binding network from the above has been customized then that setting has to be preserved as well.

As a result of the workaround changes, the 'KeystoneAdminVip' is not relocated on the 'ctlplane' network so that no services restart needs to be triggered.

With this update, the default network where the 'KeystoneAdminVip' is placed was changed from 'InternalApi' to 'ctlplane' so that the post-deployment Identity service initialization step could be carried by the Undercloud over the 'ctlplane' network. Relocating the 'KeystoneAdminVip' causes a cascading restart of the services pointing to the old 'KeystoneAdminVip'.

As a workaround to make sure the KeystoneAdminVip remains on the 'InternalApi' network, a customized 'ServiceNetMap' must be provided as deployment parameter when launching an update from the 7.0 release. A sample Orchestration environment file passing a customized 'ServiceNetMap' is as follows:


parameters:
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage

If any additional binding network from the above has been customized then that setting has to be preserved as well.

As a result of the workaround changes, the 'KeystoneAdminVip' is not relocated on the 'ctlplane' network so that no services restart needs to be triggered.

By default the number of heat-engine workers created will match the number of cores on the undercloud. Previously, however, if there was only one core there would only be one heat-engine worker, and this caused deadlocks when creating the overcloud stack. A single heat-engine worker was not enough to launch an overcloud stack.

To avoid this, it is recommended that the undercloud has at least two (virtual) cores. For virtual deployments this should be two vCPUs, regardless of cores on the baremetal host. If this is not possible, then uncommenting the num_engine_workers line in /etc/heat/heat.conf,  and restarting openstack-heat-engine fixes the issue. Thus, the above workarounds have resolved the issue.

By default the number of heat-engine workers created will match the number of cores on the undercloud. Previously, however, if there was only one core there would only be one heat-engine worker, and this caused deadlocks when creating the overcloud stack. A single heat-engine worker was not enough to launch an overcloud stack.

To avoid this, it is recommended that the undercloud has at least two (virtual) cores. For virtual deployments this should be two vCPUs, regardless of cores on the baremetal host. If this is not possible, then uncommenting the num_engine_workers line in /etc/heat/heat.conf,  and restarting openstack-heat-engine fixes the issue. Thus, the above workarounds have resolved the issue.

At present, policy rules for volume extension prevent you from taking snapshots of in-use GlusterFS volumes. To work around this, you will have to manually edit those policy rules.

To do so, open the Compute service's policy.json file and change "rule:admin_api" entries to "" for "compute_extension:os-assisted-volume-snapshots:create" and "compute_extension:os-assisted-volume-snapshots:delete". Afterwards, restart the Compute API service.

At present, policy rules for volume extension prevent you from taking snapshots of in-use GlusterFS volumes. To work around this, you will have to manually edit those policy rules.

To do so, open the Compute service's policy.json file and change "rule:admin_api" entries to "" for "compute_extension:os-assisted-volume-snapshots:create" and "compute_extension:os-assisted-volume-snapshots:delete". Afterwards, restart the Compute API service.

The underlying Database-as-a-Service (Trove) processes will not start if the service's back-end database is unreachable. To work around this, Database-as-a-Service must be deployed on the same node as its back-end database.

The underlying Database-as-a-Service (Trove) processes will not start if the service's back-end database is unreachable. To work around this, Database-as-a-Service must be deployed on the same node as its back-end database.

Sometimes bare metal nodes can lock into a certain state if ironic-conductor stops abruptly. This means users cannot delete these nodes or change their state. As a workaround, log into the director's database and use the following query to set the node back to "available" state and remove the lock:

UPDATE nodes SET provision_state="available", target_provision_state=NULL, reservation=NULL WHERE uuid=<node uuid>;

Sometimes bare metal nodes can lock into a certain state if ironic-conductor stops abruptly. This means users cannot delete these nodes or change their state. As a workaround, log into the director's database and use the following query to set the node back to "available" state and remove the lock:

UPDATE nodes SET provision_state="available", target_provision_state=NULL, reservation=NULL WHERE uuid=<node uuid>;

Due to a known issue with the 'python-neutron-fwaas' package, Firewall-as-a-Service (FWaaS) may fail to work. This is a result of the 'python-neutron-fwaas' package missing the database upgrade 'versions' directory.
In addition, upgrading the database schemas between version releases may not function correctly at this time.

Due to a known issue with the 'python-neutron-fwaas' package, Firewall-as-a-Service (FWaaS) may fail to work. This is a result of the 'python-neutron-fwaas' package missing the database upgrade 'versions' directory.
In addition, upgrading the database schemas between version releases may not function correctly at this time.

In rare cases, RabbitMQ fails to start on deployment. As a workaround, manually start RabbitMQ on nodes:

[stack@director ~]$ ssh heat-admin@192.168.0.20
[heat-admin@overcloud-controller-0 ~]$ pcs resource debug-start rabbitmq

Then rerun the deployment command on the director. The deployment now succeeds.

In rare cases, RabbitMQ fails to start on deployment. As a workaround, manually start RabbitMQ on nodes:

[stack@director ~]$ ssh heat-admin@192.168.0.20
[heat-admin@overcloud-controller-0 ~]$ pcs resource debug-start rabbitmq

Then rerun the deployment command on the director. The deployment now succeeds.

On the Undercloud, HAProxy is configured to run a HTTP check against the openstack-ironic-api service every 2 seconds. The check causes openstack-ironic-api to log a traceback to stderr with the errors:

 error: [Errno 104] Connection reset by peer
 error: [Errno 32] Broken pipe

Since the check runs every 2 seconds, these messages repeat frequently in /var/log/messages. As a workaround, switch to root permissions, edit /etc/haproxy/haproxy.cfg, and comment out the "option httpchk GET /" line from the ironic listener configuration:

 listen ironic
   bind 192.0.2.2:6385
   bind 192.0.2.3:6385
   # option httpchk GET /
   server 192.0.2.1 192.0.2.1:6385 check fall 5 inter 2000 rise 2

Save the file, then restart haproxy:

 sudo systemctl restart haproxy

No tracebacks from openstack-ironic-api are written to stderr.

On the Undercloud, HAProxy is configured to run a HTTP check against the openstack-ironic-api service every 2 seconds. The check causes openstack-ironic-api to log a traceback to stderr with the errors:

 error: [Errno 104] Connection reset by peer
 error: [Errno 32] Broken pipe

Since the check runs every 2 seconds, these messages repeat frequently in /var/log/messages. As a workaround, switch to root permissions, edit /etc/haproxy/haproxy.cfg, and comment out the "option httpchk GET /" line from the ironic listener configuration:

 listen ironic
   bind 192.0.2.2:6385
   bind 192.0.2.3:6385
   # option httpchk GET /
   server 192.0.2.1 192.0.2.1:6385 check fall 5 inter 2000 rise 2

Save the file, then restart haproxy:

 sudo systemctl restart haproxy

No tracebacks from openstack-ironic-api are written to stderr.

Multiple services attempted NTP configuration on the Overcloud and the last service configured it incorrectly. This caused time synchronization issues across all Overcloud nodes. As a workaround, delete /usr/libexec/os-apply-config/templates/etc/ntp.conf from all Overcloud nodes and re-run the deployment command to re-apply the puppet configuration. This is required for users updating from an older version of Red Hat OpenStack Platform to 7.3. This fix is not necessary on new 7.3 deployments. NTP now configures correctly.

Multiple services attempted NTP configuration on the Overcloud and the last service configured it incorrectly. This caused time synchronization issues across all Overcloud nodes. As a workaround, delete /usr/libexec/os-apply-config/templates/etc/ntp.conf from all Overcloud nodes and re-run the deployment command to re-apply the puppet configuration. This is required for users updating from an older version of Red Hat OpenStack Platform to 7.3. This fix is not necessary on new 7.3 deployments. NTP now configures correctly.

All keystone endpoints are on the External VIP. This means all API calls to keystone happen over the External VIP. There is no workaround at this time.

All keystone endpoints are on the External VIP. This means all API calls to keystone happen over the External VIP. There is no workaround at this time.

When using the 'gluster_native' driver for File Share Service back ends, snapshot commands can fail ungracefully with a 'key error' if any of the following components are down in the back end cluster's nodes:

- Logical volume brick
- The glusterd service
- Red Hat Gluster Storage volume

In addition, the following could also cause the same error:

- An entire node in a cluster is down.
- An unsupported volume is used as a back end.

Specifically, these issues can cause the 'openstack-manila-share' service to produce a traceback with KeyError instead of producing a useful error message. When troubleshooting this error, consider these possible back end issues.

When using the 'gluster_native' driver for File Share Service back ends, snapshot commands can fail ungracefully with a 'key error' if any of the following components are down in the back end cluster's nodes:

- Logical volume brick
- The glusterd service
- Red Hat Gluster Storage volume

In addition, the following could also cause the same error:

- An entire node in a cluster is down.
- An unsupported volume is used as a back end.

Specifically, these issues can cause the 'openstack-manila-share' service to produce a traceback with KeyError instead of producing a useful error message. When troubleshooting this error, consider these possible back end issues.

The OpenStack Dashboard (Horizon) is not configured to accept connections on its local IP address. This mean you cannot browse the OpenStack Dashboard, including the Undercloud UI by IP address. As a workaround, use the Undercloud's FQDN instead of IP address. If access through the IP address is desired, edit /etc/openstack-dashboard/local_settings, add the IP address to the ALLOWED_HOSTS setting, then restart the httpd service. This enables the ability to browse OpenStack Dashboard through the host IP address.

The OpenStack Dashboard (Horizon) is not configured to accept connections on its local IP address. This mean you cannot browse the OpenStack Dashboard, including the Undercloud UI by IP address. As a workaround, use the Undercloud's FQDN instead of IP address. If access through the IP address is desired, edit /etc/openstack-dashboard/local_settings, add the IP address to the ALLOWED_HOSTS setting, then restart the httpd service. This enables the ability to browse OpenStack Dashboard through the host IP address.

With the glusterFS_native driver, providing or revoking 'cert'-based access to a share restarts a Red Hat Gluster Storage volume. This, in turn, will disrupt any ongoing I/O to existing mounts. To prevent any data loss, unmount a share on all clients before allowing or denying access to it.

With the glusterFS_native driver, providing or revoking 'cert'-based access to a share restarts a Red Hat Gluster Storage volume. This, in turn, will disrupt any ongoing I/O to existing mounts. To prevent any data loss, unmount a share on all clients before allowing or denying access to it.

The 'manila list' command shows information on all shares available from the File Share Service. This command also shows the Export Location field of each one, which should provide information for composing its mount point entry in an instance. However, the field displays this information in the following format:

    user@host:/vol
    
The 'user@' prefix is unnecessary, and should therefore be ignored when composing its mount point entry.

The 'manila list' command shows information on all shares available from the File Share Service. This command also shows the Export Location field of each one, which should provide information for composing its mount point entry in an instance. However, the field displays this information in the following format:

    user@host:/vol
    
The 'user@' prefix is unnecessary, and should therefore be ignored when composing its mount point entry.

With the the File Share Service, when an attempt to create a snapshot of a provisioned share fails, an entry for the snapshot will still be created. However, this entry will be in an 'error' state, and any attempts to delete it will fail. 

To prevent this, avoid creating share snapshots if the back end volume, service, or host is down.

With the the File Share Service, when an attempt to create a snapshot of a provisioned share fails, an entry for the snapshot will still be created. However, this entry will be in an 'error' state, and any attempts to delete it will fail. 

To prevent this, avoid creating share snapshots if the back end volume, service, or host is down.

OpenStack command-line clients that use `python-requests` can not currently validate certificates that have an IP address in the SAN field.

OpenStack command-line clients that use `python-requests` can not currently validate certificates that have an IP address in the SAN field.