Release Notes

Compatibility Mode

#subscription-manager repos --enable=[reponame]
#subscription-manager repos --enable=[reponame]
#subscription-manager repos --disable=[reponame]
#subscription-manager repos --disable=[reponame]
source ~/stackrc
(undercloud) [stack@director-12 ~]$
[stack@director-12 ~]$ source ~/stackrc
(undercloud) [stack@director-12 ~]$

This update provides the Docker image for the Keystone service.
This update provides the Docker image for the Keystone service.
This update adds support to OpenStack Bare Metal (ironic) for the Emulex hardware iSCSI (be2iscsi) ramdisk.
This update adds support to OpenStack Bare Metal (ironic) for the Emulex hardware iSCSI (be2iscsi) ramdisk.
This updates adds new commands that allow you to determine host to IP mapping from the undercloud without needing to access the hosts directly.

You can show which IP addresses are assigned to which host and to which port with the following command: openstack stack output show overcloud HostsEntry -c output_value -f value

Use grep to filter the results for a specific host.

You can also map the hosts to bare metal nodes with the following command: openstack baremetal node list --fields uuid name instance_info -f json
This updates adds new commands that allow you to determine host to IP mapping from the undercloud without needing to access the hosts directly.

You can show which IP addresses are assigned to which host and to which port with the following command: openstack stack output show overcloud HostsEntry -c output_value -f value

Use grep to filter the results for a specific host.

You can also map the hosts to bare metal nodes with the following command: openstack baremetal node list --fields uuid name instance_info -f json
Uploading to and downloading from Cinder volumes with Glance is now supported with the Cinder backend driver.

Note: This update does not include support for Ceph RBD. Use the Ceph backend driver to perform RBD operations on Ceph volumes.
Uploading to and downloading from Cinder volumes with Glance is now supported with the Cinder backend driver.

Note: This update does not include support for Ceph RBD. Use the Ceph backend driver to perform RBD operations on Ceph volumes.
The update adds a new validation to check the overcloud's network environment. This helps avoid any conflicts with IP addresses, VLANs, and allocation pool when deploying your overcloud.
The update adds a new validation to check the overcloud's network environment. This helps avoid any conflicts with IP addresses, VLANs, and allocation pool when deploying your overcloud.
You can now set QoS IOPS limits that scale per GB size of the volume with the options "total_iops_sec_per_gb", "read_iops_sec_per_gb", and "write_iops_sec_per_gb". 

For example, if you set the total_iops_sec_per_gb=1000 option, you will get 1000 IOPS for a 1GB volume, 2000 IOPS for a 2GB volume, and so on.
You can now set QoS IOPS limits that scale per GB size of the volume with the options "total_iops_sec_per_gb", "read_iops_sec_per_gb", and "write_iops_sec_per_gb". 

For example, if you set the total_iops_sec_per_gb=1000 option, you will get 1000 IOPS for a 1GB volume, 2000 IOPS for a 2GB volume, and so on.
The update adds a new validation to check the hardware resource on the undercloud before an deployment or upgrade. The validation ensures the undercloud meets the necessary disk space and memory requirements prior to a deployment or upgrade.
The update adds a new validation to check the hardware resource on the undercloud before an deployment or upgrade. The validation ensures the undercloud meets the necessary disk space and memory requirements prior to a deployment or upgrade.
This update adds an action to "Manage Nodes" through the director UI. This action switches nodes to a "manageable" state so the director can perform introspection through the UI.
This update adds an action to "Manage Nodes" through the director UI. This action switches nodes to a "manageable" state so the director can perform introspection through the UI.
Director now supports the creation of custom networks during the deployment and update phases. These additional networks can be used for dedicated network controllers, Ironic baremetal nodes, system management, or to create separate networks for different roles.

A single data file ('network_data.yaml') manages the list of networks that will be deployed. The role definition process then assigns the networks to the required roles.
Director now supports the creation of custom networks during the deployment and update phases. These additional networks can be used for dedicated network controllers, Ironic baremetal nodes, system management, or to create separate networks for different roles.

A single data file ('network_data.yaml') manages the list of networks that will be deployed. The role definition process then assigns the networks to the required roles.
This update increases the granularity of the deployment progress bar. This is achieved with an increase in the nesting level that retrieves the stack resources. This provides more accurate progress of a deployment.
This update increases the granularity of the deployment progress bar. This is achieved with an increase in the nesting level that retrieves the stack resources. This provides more accurate progress of a deployment.
Previously, the OS_IMAGE_API_VERSION and the OS_VOLUME_API_VERSION environment variables were not set, which forced Glance and Cinder to fall back to the default API versions. For Cinder, this was the older v2 API.

With this update, the overcloudrc file now sets the environment variables to specify the API versions for Glance and Cinder.
Previously, the OS_IMAGE_API_VERSION and the OS_VOLUME_API_VERSION environment variables were not set, which forced Glance and Cinder to fall back to the default API versions. For Cinder, this was the older v2 API.

With this update, the overcloudrc file now sets the environment variables to specify the API versions for Glance and Cinder.
With the Manila service, you can now create shares within Consistency Groups to guarantee snapshot consistency across multiple shares. Driver vendors must report this capability and implement its functions to work according to the back end.

This feature is not recommended for production cloud environments, as it is still in its experimental stage.
With the Manila service, you can now create shares within Consistency Groups to guarantee snapshot consistency across multiple shares. Driver vendors must report this capability and implement its functions to work according to the back end.

This feature is not recommended for production cloud environments, as it is still in its experimental stage.
Containerized deployment of the OpenStack File Share Service (manila) is available as a technology preview in this release. By default, Manila, Cinder, and Neutron will still be deployed on bare metal machines.
Containerized deployment of the OpenStack File Share Service (manila) is available as a technology preview in this release. By default, Manila, Cinder, and Neutron will still be deployed on bare metal machines.
POWER-8 (ppc64le) Compute support is now available as a technology preview.
POWER-8 (ppc64le) Compute support is now available as a technology preview.
When TLS everywhere is enabled, the HAProxy stats interface will also use TLS. As a result, you will need to access the interface though the individual node's ctlplane address, which is either the actual IP address or the FQDN (using the convention <node name>.ctlplane.<domain>, for example, overcloud-controller-0.ctlplane.example.com). This setting can be configured by the `CloudNameCtlplane` parameter in `tripleo-heat-templates`. Note that you can still use the `haproxy_stats_certificate` parameter from the HAproxy class, and it will take precedence if set.
When TLS everywhere is enabled, the HAProxy stats interface will also use TLS. As a result, you will need to access the interface though the individual node's ctlplane address, which is either the actual IP address or the FQDN (using the convention <node name>.ctlplane.<domain>, for example, overcloud-controller-0.ctlplane.example.com). This setting can be configured by the `CloudNameCtlplane` parameter in `tripleo-heat-templates`. Note that you can still use the `haproxy_stats_certificate` parameter from the HAproxy class, and it will take precedence if set.
There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.
There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.
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.
When an overcloud image is shipped with 'tuned' version lower than 2.7.1-4, you should apply a manual update of the 'tuned' package to the overcloud image. If the 'tuned' version is equal to 2.7.1-4 or higher, you should provide the list of the core to 'tuned' and activate the profile, for example:

# echo "isolated_cores=2,4,6,8,10,12,14,18,20,22,24,26,28,30" >> /etc/tuned/cpu-partitioning-variables.conf
# tuned-adm profile cpu-partitioning

This is a known issue until the 'tuned' packages are available in the Centos repositories.
When an overcloud image is shipped with 'tuned' version lower than 2.7.1-4, you should apply a manual update of the 'tuned' package to the overcloud image. If the 'tuned' version is equal to 2.7.1-4 or higher, you should provide the list of the core to 'tuned' and activate the profile, for example:

# echo "isolated_cores=2,4,6,8,10,12,14,18,20,22,24,26,28,30" >> /etc/tuned/cpu-partitioning-variables.conf
# tuned-adm profile cpu-partitioning

This is a known issue until the 'tuned' packages are available in the Centos repositories.
The '--controller-count' option for the 'openstack overcloud deploy' command sets the 'NeutronDhcpAgentsPerNetwork' parameter. When deploying a custom Networker role that hosts the OpenStack Networking (neutron) DHCP Agent, the 'NeutronDhcpAgentsPerNetwork' parameter might not set to the correct value. As a workaround, set the 'NeutronDhcpAgentsPerNetwork' parameter manually using an environment file. For example:

----
parameter_defaults:
  NeutronDhcpAgentsPerNetwork: 3
----

This sets 'NeutronDhcpAgentsPerNetwork' to the correct value.
The '--controller-count' option for the 'openstack overcloud deploy' command sets the 'NeutronDhcpAgentsPerNetwork' parameter. When deploying a custom Networker role that hosts the OpenStack Networking (neutron) DHCP Agent, the 'NeutronDhcpAgentsPerNetwork' parameter might not set to the correct value. As a workaround, set the 'NeutronDhcpAgentsPerNetwork' parameter manually using an environment file. For example:

----
parameter_defaults:
  NeutronDhcpAgentsPerNetwork: 3
----

This sets 'NeutronDhcpAgentsPerNetwork' to the correct value.
When using an NFS back end for the Image service (glance), attempting to create an image will fail with a permission error. This is because the user ID on the host and container differ, and also because puppet cannot mount the NFS endpoint successfully on the container.
When using an NFS back end for the Image service (glance), attempting to create an image will fail with a permission error. This is because the user ID on the host and container differ, and also because puppet cannot mount the NFS endpoint successfully on the container.
Encrypted volumes cannot attach correctly to instances in containerized environments. The Compute service runs "cryptsetup luksOpen", which waits for the udev device creation process to finish. This process does not actually finish, which causes the command to hang.

Workaround: Restart the containerized Compute service with the docker option "--ipc=host".
Encrypted volumes cannot attach correctly to instances in containerized environments. The Compute service runs "cryptsetup luksOpen", which waits for the udev device creation process to finish. This process does not actually finish, which causes the command to hang.

Workaround: Restart the containerized Compute service with the docker option "--ipc=host".
For containerized OpenStack services, configuration files are now installed in each container. However, some OpenStack services are not containerized yet, and configuration files for those services are still installed on the bare metal nodes. 

If you need to access or modify configuration files for containerized services, use /var/log/config-data/<container name>/<config path>. For services that are not containerized yet, use /etc/<service>.
For containerized OpenStack services, configuration files are now installed in each container. However, some OpenStack services are not containerized yet, and configuration files for those services are still installed on the bare metal nodes. 

If you need to access or modify configuration files for containerized services, use /var/log/config-data/<container name>/<config path>. For services that are not containerized yet, use /etc/<service>.
In HP DL 360/380 Gen9, the DIMM format does not match the regex query.

In order to PASS on this, you must cherry-pick the HW patches in comment #2.
In HP DL 360/380 Gen9, the DIMM format does not match the regex query.

In order to PASS on this, you must cherry-pick the HW patches in comment #2.
There is currently a known issue with LDAP integration for Red Hat OpenStack Platform. At present, the `keystone_domain_confg` tag is missing from `keystone.yaml`, preventing Puppet from properly applying the required configuration files. Consequently, LDAP integration with Red Hat OpenStack Platform will not be properly configured. As a workaround, you will need to manually edit `keystone.yaml` and add the missing tag. There are two ways to do this:

1. Edit the the file directly:
  a. Log into the undercloud as the stack user.
  b. Open the keystone.yaml in the editor of your choice. For example:
       `sudo vi /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Append the missing puppet tag, `keystone_domain_confg`, to line 94. For example:
      `puppet_tags: keystone_config`
        Changes to:
      `puppet_tags: keystone_config,keystone_domain_confg`
  d. Save and close `keystone.yaml`.
  e. Verify you see the missing tag in the `keystone.yaml` file. The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/sercies/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

2. Or, use sed to edit the file inline:
  a. Login to the undercloud as the stack user.
  b. Run the following command to add the missing puppet tag:
     `sed -i 's/puppet_tags\: keystone_config/puppet_tags\: keystone_config,keystone_domain_config/' /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Verify you see the missing tag in the keystone.yaml file The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/sercies/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`
There is currently a known issue with LDAP integration for Red Hat OpenStack Platform. At present, the `keystone_domain_confg` tag is missing from `keystone.yaml`, preventing Puppet from properly applying the required configuration files. Consequently, LDAP integration with Red Hat OpenStack Platform will not be properly configured. As a workaround, you will need to manually edit `keystone.yaml` and add the missing tag. There are two ways to do this:

1. Edit the the file directly:
  a. Log into the undercloud as the stack user.
  b. Open the keystone.yaml in the editor of your choice. For example:
       `sudo vi /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Append the missing puppet tag, `keystone_domain_confg`, to line 94. For example:
      `puppet_tags: keystone_config`
        Changes to:
      `puppet_tags: keystone_config,keystone_domain_confg`
  d. Save and close `keystone.yaml`.
  e. Verify you see the missing tag in the `keystone.yaml` file. The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/sercies/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

2. Or, use sed to edit the file inline:
  a. Login to the undercloud as the stack user.
  b. Run the following command to add the missing puppet tag:
     `sed -i 's/puppet_tags\: keystone_config/puppet_tags\: keystone_config,keystone_domain_config/' /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Verify you see the missing tag in the keystone.yaml file The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/sercies/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`
You must manually discover the latest Docker image tags for current container images that are stored in Red Hat Satellite. For more information, see the Red Hat Satellite documentation: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_container_images#managing_container_images_with_docker_tags
You must manually discover the latest Docker image tags for current container images that are stored in Red Hat Satellite. For more information, see the Red Hat Satellite documentation: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_container_images#managing_container_images_with_docker_tags
It is only possible to deploy Ceph storage servers if their disk devices are homogeneous.
It is only possible to deploy Ceph storage servers if their disk devices are homogeneous.
OpenStack Compute (nova) provides both versioned and unversioned notifications in RabbitMQ. However, due to the lack of consumers for versioned notifications, the  versioned notifications queue grows quickly and causes RabbitMQ failures. This can hinder Compute operations such as instance creation and flavor creation. Red Hat is currently implementing fixes for RabbitMQ and director:

https://bugzilla.redhat.com/show_bug.cgi?id=1478274
https://bugzilla.redhat.com/show_bug.cgi?id=1488499

The following article provides a workaround until Red Hat releases patches for this issue:

https://access.redhat.com/solutions/3139721
OpenStack Compute (nova) provides both versioned and unversioned notifications in RabbitMQ. However, due to the lack of consumers for versioned notifications, the  versioned notifications queue grows quickly and causes RabbitMQ failures. This can hinder Compute operations such as instance creation and flavor creation. Red Hat is currently implementing fixes for RabbitMQ and director:

https://bugzilla.redhat.com/show_bug.cgi?id=1478274
https://bugzilla.redhat.com/show_bug.cgi?id=1488499

The following article provides a workaround until Red Hat releases patches for this issue:

https://access.redhat.com/solutions/3139721
For deployments using OVN as the ML2 mechanism driver, only nodes with connectivity to the external networks are eligible to schedule the router gateway ports on them. However, there is currently a known issue that will make all nodes as eligible, which becomes a problem when the Compute nodes do not have external connectivity. As a result, if a router gateway port is scheduled on Compute nodes without external connectivity, ingress and egress connections for the external networks will not work; in which case the router gateway port has to be rescheduled to a controller node. As a workaround, you can provide connectivity on all your compute nodes, or you can consider deleting NeutronBridgeMappings, or set it to datacentre:br-ex. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1525520 and https://bugzilla.redhat.com/show_bug.cgi?id=1510879.
For deployments using OVN as the ML2 mechanism driver, only nodes with connectivity to the external networks are eligible to schedule the router gateway ports on them. However, there is currently a known issue that will make all nodes as eligible, which becomes a problem when the Compute nodes do not have external connectivity. As a result, if a router gateway port is scheduled on Compute nodes without external connectivity, ingress and egress connections for the external networks will not work; in which case the router gateway port has to be rescheduled to a controller node. As a workaround, you can provide connectivity on all your compute nodes, or you can consider deleting NeutronBridgeMappings, or set it to datacentre:br-ex. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1525520 and https://bugzilla.redhat.com/show_bug.cgi?id=1510879.
The Panko service is officially deprecated in OpenStack version 12. Support for panko will be limited to usage from cloudforms only. We do not recommend using panko outside of the cloudforms use case.
The Panko service is officially deprecated in OpenStack version 12. Support for panko will be limited to usage from cloudforms only. We do not recommend using panko outside of the cloudforms use case.
VPN-as-a-Service (VPNaaS) VPNaaS was deprecated in Red Hat OpenStack Platform 11, and has now been removed in Red Hat OpenStack Platform 12.
VPN-as-a-Service (VPNaaS) VPNaaS was deprecated in Red Hat OpenStack Platform 11, and has now been removed in Red Hat OpenStack Platform 12.
MongoDB is no longer used by Red Hat OpenStack Platform. Previously, it was used for Telemetry (which now uses Gnocchi) and Zaqar on the undercloud (which is moving to Redis). As a result, 'mongodb', 'puppet-mongodb', and 'v8' are no longer included.
MongoDB is no longer used by Red Hat OpenStack Platform. Previously, it was used for Telemetry (which now uses Gnocchi) and Zaqar on the undercloud (which is moving to Redis). As a result, 'mongodb', 'puppet-mongodb', and 'v8' are no longer included.
File injection from the Compute REST API. This will continue to be supported for now if using API microversion < 2.56. However, Compute will eventually remove this functionality. The changes are as follows:

* Deprecate the 'personality' parameter from the 'POST /servers' create server API and the 'POST /servers/{server_id}/action' rebuild server API. Specifying the 'personality' parameter in the request body to either of these APIs will result in a '400 Bad Request' error response. 

* Add support to pass 'user_data' to the rebuild server API as a result of this change.

* Stop returning 'maxPersonality' and 'maxPersonalitySize' response values from the 'GET /limits' API.

* Stop accepting and returning 'injected_files', 'injected_file_path_bytes', 'injected_file_content_bytes' from the 'os-quota-sets' and 'os-quota-class-sets' APIs.

* Removes Compute API extensions including server extensions, flavor extensions and image extensions.. The extensions code have their own policy and there is no option to enable or disable these extensions in the API, leading to interoperability issues. 

* Removes the 'hide_server_address_states' configuration option which allows you to configure the server states to hide the address and the hide server address policy. Also, removes the 'os_compute_api:os-hide-server-addresses' policy as it is no longer necessary.
File injection from the Compute REST API. This will continue to be supported for now if using API microversion < 2.56. However, Compute will eventually remove this functionality. The changes are as follows:

* Deprecate the 'personality' parameter from the 'POST /servers' create server API and the 'POST /servers/{server_id}/action' rebuild server API. Specifying the 'personality' parameter in the request body to either of these APIs will result in a '400 Bad Request' error response. 

* Add support to pass 'user_data' to the rebuild server API as a result of this change.

* Stop returning 'maxPersonality' and 'maxPersonalitySize' response values from the 'GET /limits' API.

* Stop accepting and returning 'injected_files', 'injected_file_path_bytes', 'injected_file_content_bytes' from the 'os-quota-sets' and 'os-quota-class-sets' APIs.

* Removes Compute API extensions including server extensions, flavor extensions and image extensions.. The extensions code have their own policy and there is no option to enable or disable these extensions in the API, leading to interoperability issues. 

* Removes the 'hide_server_address_states' configuration option which allows you to configure the server states to hide the address and the hide server address policy. Also, removes the 'os_compute_api:os-hide-server-addresses' policy as it is no longer necessary.
There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.
There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.
When using the Docker CLI to report the state of running containers, the nova_migration_target container might be incorrectly reported as "unhealthy". This is due to an issue with the health check itself, and not with an accurate reflection of the state of the running container.
When using the Docker CLI to report the state of running containers, the nova_migration_target container might be incorrectly reported as "unhealthy". This is due to an issue with the health check itself, and not with an accurate reflection of the state of the running container.
There is currently a known issue with LDAP integration for Red Hat OpenStack Platform. At present, the `keystone_domain_confg` tag is missing from `keystone.yaml`, preventing Puppet from properly applying the required configuration files. Consequently, LDAP integration with Red Hat OpenStack Platform will not be properly configured. As a workaround, you will need to manually edit `keystone.yaml` and add the missing tag. There are two ways to do this:

1. Edit the the file directly:
  a. Log into the undercloud as the stack user.
  b. Open the keystone.yaml in the editor of your choice. For example:
       `sudo vi /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Append the missing puppet tag, `keystone_domain_confg`, to line 94. For example:
      `puppet_tags: keystone_config`
        Changes to:
      `puppet_tags: keystone_config,keystone_domain_confg`
  d. Save and close `keystone.yaml`.
  e. Verify you see the missing tag in the `keystone.yaml` file. The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

2. Or, use sed to edit the file inline:
  a. Login to the undercloud as the stack user.
  b. Run the following command to add the missing puppet tag:
     `sed -i 's/puppet_tags\: keystone_config/puppet_tags\: keystone_config,keystone_domain_config/' /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Verify you see the missing tag in the keystone.yaml file The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`
There is currently a known issue with LDAP integration for Red Hat OpenStack Platform. At present, the `keystone_domain_confg` tag is missing from `keystone.yaml`, preventing Puppet from properly applying the required configuration files. Consequently, LDAP integration with Red Hat OpenStack Platform will not be properly configured. As a workaround, you will need to manually edit `keystone.yaml` and add the missing tag. There are two ways to do this:

1. Edit the the file directly:
  a. Log into the undercloud as the stack user.
  b. Open the keystone.yaml in the editor of your choice. For example:
       `sudo vi /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Append the missing puppet tag, `keystone_domain_confg`, to line 94. For example:
      `puppet_tags: keystone_config`
        Changes to:
      `puppet_tags: keystone_config,keystone_domain_confg`
  d. Save and close `keystone.yaml`.
  e. Verify you see the missing tag in the `keystone.yaml` file. The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`

2. Or, use sed to edit the file inline:
  a. Login to the undercloud as the stack user.
  b. Run the following command to add the missing puppet tag:
     `sed -i 's/puppet_tags\: keystone_config/puppet_tags\: keystone_config,keystone_domain_config/' /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml`
  c. Verify you see the missing tag in the keystone.yaml file The following command should return '1':
    `cat /usr/share/openstack-tripleo-heat-templates/docker/services/keystone.yaml | grep 'puppet_tags: keystone_config,keystone_domain_config' | wc -l`
It is only possible to deploy Ceph storage servers if their disk devices are homogeneous.
It is only possible to deploy Ceph storage servers if their disk devices are homogeneous.
For deployments using OVN as the ML2 mechanism driver, only nodes with connectivity to the external networks are eligible to schedule the router gateway ports on them. However, there is a known issue that marks all nodes as eligible, which becomes a problem when the Compute nodes do not have external connectivity. 

As a result, if a router gateway port is scheduled on Compute nodes without external connectivity, ingress and egress connections for the external networks will not work; in which case the router gateway port has to be rescheduled to a controller node. 

As a workaround, you can provide connectivity on all your compute nodes, or you can consider deleting NeutronBridgeMappings, or set it to datacentre:br-ex. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1525520 and https://bugzilla.redhat.com/show_bug.cgi?id=1510879.
For deployments using OVN as the ML2 mechanism driver, only nodes with connectivity to the external networks are eligible to schedule the router gateway ports on them. However, there is a known issue that marks all nodes as eligible, which becomes a problem when the Compute nodes do not have external connectivity. 

As a result, if a router gateway port is scheduled on Compute nodes without external connectivity, ingress and egress connections for the external networks will not work; in which case the router gateway port has to be rescheduled to a controller node. 

As a workaround, you can provide connectivity on all your compute nodes, or you can consider deleting NeutronBridgeMappings, or set it to datacentre:br-ex. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1525520 and https://bugzilla.redhat.com/show_bug.cgi?id=1510879.
Due to the migration from puppet-ceph to ceph-ansible for the management of Ceph using Director, old puppet hieradata (such as ceph::profile::params::osds) needs to be migrated to the ceph-ansible format.

          Customizations for the Ceph deployment previously passed as hieradata from *ExtraConfig should be removed since they are ignored. Specifically, the deployment will stop if ceph::profile::params::osds is found to ensure the devices list has been migrated to the format expected by ceph-ansible. 

          Use the CephAnsibleExtraConfig and CephAnsibleDisksConfig parameters to pass arbitrary variables to ceph-ansible, such devices and dedicated_devices.
Due to the migration from puppet-ceph to ceph-ansible for the management of Ceph using Director, old puppet hieradata (such as ceph::profile::params::osds) needs to be migrated to the ceph-ansible format.

          Customizations for the Ceph deployment previously passed as hieradata from *ExtraConfig should be removed since they are ignored. Specifically, the deployment will stop if ceph::profile::params::osds is found to ensure the devices list has been migrated to the format expected by ceph-ansible. 

          Use the CephAnsibleExtraConfig and CephAnsibleDisksConfig parameters to pass arbitrary variables to ceph-ansible, such devices and dedicated_devices.
There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.
There is currently a known issue where you cannot use ACLs to make a container public for anonymous access. This issue arises when sending `POST` operations to Swift that specify a '*' value in the `X-Container-Read` or `X-Container-Write` settings.
This update helps operators locate log files after an upgrade from a non-containerized to a containerized deployment.

If old log files are present when the upgrade begins, the old files are moved to a new file location. A readme.txt file is placed in the old file location. The file points to the new log file location.

For example, if a /var/log/nova directory exists, a /var/log/nova/readme.txt file is created, advising the reader to look in the /var/log/containers/nova directory instead.
This update helps operators locate log files after an upgrade from a non-containerized to a containerized deployment.

If old log files are present when the upgrade begins, the old files are moved to a new file location. A readme.txt file is placed in the old file location. The file points to the new log file location.

For example, if a /var/log/nova directory exists, a /var/log/nova/readme.txt file is created, advising the reader to look in the /var/log/containers/nova directory instead.
This update prevents CPU pinning mismatches during Nova live migrations.

Prior to the update, the scheduler did not check whether the guest CPU pinning configuration was supported on the host. A mismatch of CPU pinning caused errors during bootup of the the host. This failed scenario could be repeated over a series of potential hosts.

A new condition in the NUMATopologyFilter filter identifies hosts with proper CPU pinning capability. If no suitable hosts are available, the migration fails quickly with an error message.
This update prevents CPU pinning mismatches during Nova live migrations.

Prior to the update, the scheduler did not check whether the guest CPU pinning configuration was supported on the host. A mismatch of CPU pinning caused errors during bootup of the the host. This failed scenario could be repeated over a series of potential hosts.

A new condition in the NUMATopologyFilter filter identifies hosts with proper CPU pinning capability. If no suitable hosts are available, the migration fails quickly with an error message.
This change allows TripleO to deploy Cinder with a Dell EMC VNX backend.
This change allows TripleO to deploy Cinder with a Dell EMC VNX backend.
Cinder volume migration between different availability zones is now supported.
Cinder volume migration between different availability zones is now supported.
Keystone user passwords generated by Heat resources such as WaitConditionHandle now meet more stringent regular expression-based password complexity requirements. The new passwords are 32-character random strings containing at least one uppercase and one lowercase letter, one digit, and one of the characters '!@#%^&*'. These passwords should pass the standard of virtually any regular expression-based password validation.

Previously, generated passwords took the form of 32 hexadecimal digits, and thus never contained uppercase letters or special characters.
Keystone user passwords generated by Heat resources such as WaitConditionHandle now meet more stringent regular expression-based password complexity requirements. The new passwords are 32-character random strings containing at least one uppercase and one lowercase letter, one digit, and one of the characters '!@#%^&*'. These passwords should pass the standard of virtually any regular expression-based password validation.

Previously, generated passwords took the form of 32 hexadecimal digits, and thus never contained uppercase letters or special characters.
Virtual CPUs (vCPUs) can be preempted by the hypervisor kernel thread even with strong partitioning in place (isolcpus, tuned). Preemptions are not frequent, a few per second, but with 256 descriptors per virtio queue, just one preemption of the vCPU can lead to packet drop, because the 256 slots are filled during the preemption. This is the case for network functions virtualization (NFV) VMs in which the per queue packet rate is above 1 Mpps (1 million packets per second).

This release supports two new tunable options: 'rx_queue_size' and 'tx_queue_size'. Use these options to configure the RX queue size and TX queue size of virtio NICs, respectively, to reduce packet drop.
Virtual CPUs (vCPUs) can be preempted by the hypervisor kernel thread even with strong partitioning in place (isolcpus, tuned). Preemptions are not frequent, a few per second, but with 256 descriptors per virtio queue, just one preemption of the vCPU can lead to packet drop, because the 256 slots are filled during the preemption. This is the case for network functions virtualization (NFV) VMs in which the per queue packet rate is above 1 Mpps (1 million packets per second).

This release supports two new tunable options: 'rx_queue_size' and 'tx_queue_size'. Use these options to configure the RX queue size and TX queue size of virtio NICs, respectively, to reduce packet drop.
Nova's libvirt driver now allows the specification of granular CPU feature flags when configuring CPU models.

One benefit of this change is the alleviation of a performance degradation that has been experienced on guests running with certain Intel-based virtual CPU models after application of the "Meltdown" CVE fixes. This guest performance impact is reduced by exposing the CPU feature flag 'PCID' ("Process-Context ID") to the *guest* CPU, assuming that the PCID flag is available in the physical hardware itself.

For more details, refer to the  documentation of ``[libvirt]/cpu_model_extra_flags`` in the ``nova.conf`` file for usage details.
Nova's libvirt driver now allows the specification of granular CPU feature flags when configuring CPU models.

One benefit of this change is the alleviation of a performance degradation that has been experienced on guests running with certain Intel-based virtual CPU models after application of the "Meltdown" CVE fixes. This guest performance impact is reduced by exposing the CPU feature flag 'PCID' ("Process-Context ID") to the *guest* CPU, assuming that the PCID flag is available in the physical hardware itself.

For more details, refer to the  documentation of ``[libvirt]/cpu_model_extra_flags`` in the ``nova.conf`` file for usage details.
To reduce the time spent processing security group updates in the L2 agent, conntrack deletion is now performed in a set of worker threads instead of in the main agent thread.
To reduce the time spent processing security group updates in the L2 agent, conntrack deletion is now performed in a set of worker threads instead of in the main agent thread.
A new configuration option called bridge_mac_table_size has been added for the neutron OVS agent. This value is set on every Open vSwitch bridge managed by the openvswitch-neutron-agent. The value controls the maximum number of MAC addresses that can be learned on a bridge. The default value for this new option is 50,000, which should be enough for most systems. Values outside a reasonable range (10 to 1,000,000) might be overridden by Open vSwitch.
A new configuration option called bridge_mac_table_size has been added for the neutron OVS agent. This value is set on every Open vSwitch bridge managed by the openvswitch-neutron-agent. The value controls the maximum number of MAC addresses that can be learned on a bridge. The default value for this new option is 50,000, which should be enough for most systems. Values outside a reasonable range (10 to 1,000,000) might be overridden by Open vSwitch.
You must manually discover the latest Docker image tags for current container images that are stored in Red Hat Satellite. For more information, see the Red Hat Satellite documentation: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_container_images#managing_container_images_with_docker_tags
You must manually discover the latest Docker image tags for current container images that are stored in Red Hat Satellite. For more information, see the Red Hat Satellite documentation: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_container_images#managing_container_images_with_docker_tags
MongoDB is no longer used by Red Hat OpenStack Platform. Previously, it was used for Telemetry (which now uses Gnocchi) and Zaqar on the undercloud (which is moving to Redis). As a result, 'mongodb', 'puppet-mongodb', and 'v8' are no longer included.

MongoDB is no longer used by Red Hat OpenStack Platform. Previously, it was used for Telemetry (which now uses Gnocchi) and Zaqar on the undercloud (which is moving to Redis). As a result, 'mongodb', 'puppet-mongodb', and 'v8' are no longer included.

This update adds the support for OpenDaylight, OVS-DPDK and OpenStack in the NetVirt/OVSDB scenario. This feature allows users to set up virtualized networks for their tenants using OpenDaylight and OVS_DPDK.

This update provides a new package of the OpenDaylight Carbon release that is used within the Red Hat OpenStack Platform 12.

With this update, the High Availability clustering is enabled for both the Neutron and the OpenDaylight controller.

This update replaces the Java based LevelDB in favour of the JNI package and provides the
leveldbjni-all-1.8-15.5.el7ost.x86_64 package.

The new conntrack-based SNAT implementation, enabled by default, uses the Linux netfilter framework to do the NAPT (Network Address Port Translation) and track the connection. The first
packet in a traffic is passed to the netfilter to be translated with the external IP. The following packets will use the netfilter for further inbound and outbound translation. In the netfilter, the Router ID will be
used as the Zone ID. Each zone tracks the connection in its own table. The rest of the implementation remains the same.
The conntrack mode also enables the new High Availability logic that newly considers the weight associated with each switch. Also, the switch will always keep one designated NAPT port open, which improves the performance.

This update adds ping6 support to the Neutron router internal interfaces for OpenStack using OpenDaylight.

You can now set QoS IOPS limits that scale per GB size of the volume with the options "total_iops_sec_per_gb", "read_iops_sec_per_gb", and "write_iops_sec_per_gb".

For example, if you set the total_iops_sec_per_gb=1000 option, you will get 1000 IOPS for a 1GB volume, 2000 IOPS for a 2GB volume, and so on.

You can now set QoS IOPS limits that scale per GB size of the volume with the options "total_iops_sec_per_gb", "read_iops_sec_per_gb", and "write_iops_sec_per_gb".

For example, if you set the total_iops_sec_per_gb=1000 option, you will get 1000 IOPS for a 1GB volume, 2000 IOPS for a 2GB volume, and so on.

Previously, if containers were shut down unexpectedly, Apache still left runtime files in the containers, which causes the containers to stay in a Restarting state after the host comes back up. If you use TLS everywhere, this means that the Glance and Swift services were unreachable after the host rebooted.

This fix adds runtime cleanup in the container images startup scripts. Glance and Swift services are now functioning normally after the host reboots when deployed with TLS everywhere.

Previously, if containers were shut down unexpectedly, Apache still left runtime files in the containers, which causes the containers to stay in a Restarting state after the host comes back up. If you use TLS everywhere, this means that the Glance and Swift services were unreachable after the host rebooted.

This fix adds runtime cleanup in the container images startup scripts. Glance and Swift services are now functioning normally after the host reboots when deployed with TLS everywhere.

Some deployments use Neutron provider bridges for internal traffic, such as traffic for AMQP, which causes bridges on boot are set to behave like normal switching. Because ARP broadcast packets use patch-ports to go between the integration bridge and the provider bridges, ARP storms to occur if more controllers were turned off ungracefully and then simultaneously booted up.

The new systemd service neutron-destroy-patch-ports now executes at the boot to remove the patch ports and break the connection between the integration bridge and the provider bridges. This prevents ARP storms, and the patch ports are then renewed after the openvswitch agent is started.

Some deployments use Neutron provider bridges for internal traffic, such as traffic for AMQP, which causes bridges on boot are set to behave like normal switching. Because ARP broadcast packets use patch-ports to go between the integration bridge and the provider bridges, ARP storms to occur if more controllers were turned off ungracefully and then simultaneously booted up.

The new systemd service neutron-destroy-patch-ports now executes at the boot to remove the patch ports and break the connection between the integration bridge and the provider bridges. This prevents ARP storms, and the patch ports are then renewed after the openvswitch agent is started.

The Panko service is officially deprecated in OpenStack version 12. Support for panko will be limited to usage from cloudforms only. We do not recommend using panko outside of the cloudforms use case.

This update adds support to OpenStack Bare Metal (ironic) for the Emulex hardware iSCSI (be2iscsi) ramdisk.

Previously, the OS_IMAGE_API_VERSION and the OS_VOLUME_API_VERSION environment variables were not set, which forced Glance and Cinder to fall back to the default API versions. For Cinder, this was the older v2 API.

With this update, the overcloudrc file now sets the environment variables to specify the API versions for Glance and Cinder.

Previously, the OS_IMAGE_API_VERSION and the OS_VOLUME_API_VERSION environment variables were not set, which forced Glance and Cinder to fall back to the default API versions. For Cinder, this was the older v2 API.

With this update, the overcloudrc file now sets the environment variables to specify the API versions for Glance and Cinder.

Encrypted volumes cannot attach correctly to instances in containerized environments. The Compute service runs "cryptsetup luksOpen", which waits for the udev device creation process to finish. This process does not actually finish, which causes the command to hang.

Workaround: Restart the containerized Compute service with the docker option "--ipc=host".
Encrypted volumes cannot attach correctly to instances in containerized environments. The Compute service runs "cryptsetup luksOpen", which waits for the udev device creation process to finish. This process does not actually finish, which causes the command to hang.

Workaround: Restart the containerized Compute service with the docker option "--ipc=host".
POWER-8 (ppc64le) Compute support is now available as a technology preview.

POWER-8 (ppc64le) Compute support is now available as a technology preview.

Director now supports the creation of custom networks during the deployment and update phases. These additional networks can be used for dedicated network controllers, Ironic baremetal nodes, system management, or to create separate networks for different roles.

A single data file ('network_data.yaml') manages the list of networks that will be deployed. The role definition process then assigns the networks to the required roles.

Director now supports the creation of custom networks during the deployment and update phases. These additional networks can be used for dedicated network controllers, Ironic baremetal nodes, system management, or to create separate networks for different roles.

A single data file ('network_data.yaml') manages the list of networks that will be deployed. The role definition process then assigns the networks to the required roles.

Containerized deployment of the OpenStack File Share Service (manila) is available as a technology preview in this release. By default, Manila, Cinder, and Neutron will still be deployed on bare metal machines.

Running Cinder services on bare metal machines and the Iscsid service in a container caused the services to have different iSCSI Qualified Name (IQN) values. Because the IQN is used to authenticate iSCSI connections, Cinder backup operations failed with an authentication error that was caused by an IQN mismatch.

With this fix, the Iscsid service now runs on bare metal, and all other services, such as containerized Nova and non-containerized Cinder, are configured to use the correct IQN.

Running Cinder services on bare metal machines and the Iscsid service in a container caused the services to have different iSCSI Qualified Name (IQN) values. Because the IQN is used to authenticate iSCSI connections, Cinder backup operations failed with an authentication error that was caused by an IQN mismatch.

With this fix, the Iscsid service now runs on bare metal, and all other services, such as containerized Nova and non-containerized Cinder, are configured to use the correct IQN.

When using an NFS back end for the Image service (glance), attempting to create an image will fail with a permission error. This is because the user ID on the host and container differ, and also because puppet cannot mount the NFS endpoint successfully on the container.

Previously, the ceph-osd package was a part of the common overcloud image, but was available only in a repository that requires the Ceph OSD entitlement. This entitlement is not required on OpenStack Controller and Compute nodes. The RPM dependency created by the ceph-osd package caused Yum update to fail when you tried to update the ceph-osd package without the ceph-osd entitlement, Yum update failed.

This fix removes the ceph-osd package from overcloud nodes that do not require the package. The ceph-osd package is now only required on Ceph storage nodes, including hyperconverged nodes that run Ceph OSD and Compute services. Yum update now succeeds on nodes that do not require the ceph-osd package. Ceph storage and hyperconverged nodes that require the ceph-osd package will still require the necessary Ceph OSD entitlement.

Previously, the ceph-osd package was a part of the common overcloud image, but was available only in a repository that requires the Ceph OSD entitlement. This entitlement is not required on OpenStack Controller and Compute nodes. The RPM dependency created by the ceph-osd package caused Yum update to fail when you tried to update the ceph-osd package without the ceph-osd entitlement, Yum update failed.

This fix removes the ceph-osd package from overcloud nodes that do not require the package. The ceph-osd package is now only required on Ceph storage nodes, including hyperconverged nodes that run Ceph OSD and Compute services. Yum update now succeeds on nodes that do not require the ceph-osd package. Ceph storage and hyperconverged nodes that require the ceph-osd package will still require the necessary Ceph OSD entitlement.

Using hardcoded machine IDs in templates creates multiple nodes with identical machine IDs. This prevents the Red Hat Storage Console from identifying multiple nodes.

Workaround: Generate unique machine IDs on each node and then update the /etc/machine-id file. This will ensure that the Red Hat Storage Console can identify the nodes as unique.

Using hardcoded machine IDs in templates creates multiple nodes with identical machine IDs. This prevents the Red Hat Storage Console from identifying multiple nodes.

Workaround: Generate unique machine IDs on each node and then update the /etc/machine-id file. This will ensure that the Red Hat Storage Console can identify the nodes as unique.

When an overcloud image is shipped with 'tuned' version lower than 2.7.1-4, you should apply a manual update of the 'tuned' package to the overcloud image. If the 'tuned' version is equal to 2.7.1-4 or higher, you should provide the list of the core to 'tuned' and activate the profile, for example:

# echo "isolated_cores=2,4,6,8,10,12,14,18,20,22,24,26,28,30" >> /etc/tuned/cpu-partitioning-variables.conf
# tuned-adm profile cpu-partitioning

This is a known issue until the 'tuned' packages are available in the Centos repositories.

When an overcloud image is shipped with 'tuned' version lower than 2.7.1-4, you should apply a manual update of the 'tuned' package to the overcloud image. If the 'tuned' version is equal to 2.7.1-4 or higher, you should provide the list of the core to 'tuned' and activate the profile, for example:

# echo "isolated_cores=2,4,6,8,10,12,14,18,20,22,24,26,28,30" >> /etc/tuned/cpu-partitioning-variables.conf
# tuned-adm profile cpu-partitioning

This is a known issue until the 'tuned' packages are available in the Centos repositories.

This update adds an action to "Manage Nodes" through the director UI. This action switches nodes to a "manageable" state so the director can perform introspection through the UI.

This update increases the granularity of the deployment progress bar. This is achieved with an increase in the nesting level that retrieves the stack resources. This provides more accurate progress of a deployment.

The update adds a new validation to check the overcloud's network environment. This helps avoid any conflicts with IP addresses, VLANs, and allocation pool when deploying your overcloud.

The update adds a new validation to check the hardware resource on the undercloud before an deployment or upgrade. The validation ensures the undercloud meets the necessary disk space and memory requirements prior to a deployment or upgrade.

Previously, the DHCP server configuration file for Ironic Inspector did not handle hosts that used UEFI and iPXE, which caused some UEFI and iPXE hosts to fail to boot during Ironic Introspection. This fix updates the DHCP server file `/etc/ironic-inspector/dnsmasq.conf` to handle UEFI and iPXE hosts, and now the hosts can properly boot during Ironic Introspection.

The token flush cron job has been modified to run hourly instead of once a day. This was changed because of issues being raised in larger deployments, as the operation would take too long and sometimes even fail because the transaction was too large. Note that this only affects deployments using the UUID token provider.

When TLS everywhere is enabled, the HAProxy stats interface will also use TLS. As a result, you will need to access the interface though the individual node's ctlplane address, which is either the actual IP address or the FQDN (using the convention {node-name}.ctlplane.{domain}, for example, overcloud-controller-0.ctlplane.example.com). This setting can be configured by the `CloudNameCtlplane` parameter in `tripleo-heat-templates`. Note that you can still use the `haproxy_stats_certificate` parameter from the HAproxy class, and it will take precedence if set.

Recent changes in Nova and Cinder resulted in Barbican being selected as the default encryption key manager, even when TripleO is not deploying Barbican. However, TripleO assumes that the legacy (fixed key) manager is active and selected for non-Barbican deployments. This led to broken volume encryption in non-Barbican deployments. This fix modifies the TripleO behavior to now actively configure Nova and Cinder to use the legacy key manager for non-Barbican deployments.

Uploading to and downloading from Cinder volumes with Glance is now supported with the Cinder backend driver.

Note: This update does not include support for Ceph RBD. Use the Ceph backend driver to perform RBD operations on Ceph volumes.

Uploading to and downloading from Cinder volumes with Glance is now supported with the Cinder backend driver.

Note: This update does not include support for Ceph RBD. Use the Ceph backend driver to perform RBD operations on Ceph volumes.

When showing the list of Neutron security groups, the Project column referenced the tenant ID instead of the project ID. This caused the Project column to appear blank. This fix changes the behavior of the operation to get the project ID, and now the list of Neutron security groups shows the relevant project ID in the Project column.

A race condition in the Python os.path.realpath method raised an unexpected exception. This caused an iSCSI disconnect method to unexpectedly fail. With this fix, the race condition exception is ignored. Because the symlink no longer exists, it is safe to ignore this exception. As a result, the disconnect operation succeeds, even when the race condition occurs.

The '--controller-count' option for the 'openstack overcloud deploy' command sets the 'NeutronDhcpAgentsPerNetwork' parameter. When deploying a custom Networker role that hosts the OpenStack Networking (neutron) DHCP Agent, the 'NeutronDhcpAgentsPerNetwork' parameter might not set to the correct value. As a workaround, set the 'NeutronDhcpAgentsPerNetwork' parameter manually using an environment file. For example:

----
parameter_defaults:
  NeutronDhcpAgentsPerNetwork: 3
----

This sets 'NeutronDhcpAgentsPerNetwork' to the correct value.

The '--controller-count' option for the 'openstack overcloud deploy' command sets the 'NeutronDhcpAgentsPerNetwork' parameter. When deploying a custom Networker role that hosts the OpenStack Networking (neutron) DHCP Agent, the 'NeutronDhcpAgentsPerNetwork' parameter might not set to the correct value. As a workaround, set the 'NeutronDhcpAgentsPerNetwork' parameter manually using an environment file. For example:

----
parameter_defaults:
  NeutronDhcpAgentsPerNetwork: 3
----

This sets 'NeutronDhcpAgentsPerNetwork' to the correct value.

Hot-unplugging Virtual Function I/O (VFIO) devices previously failed when performed after hot-unplugging a vhost network device. This update fixes the underlying code, and the VFIO device is unplugged correctly in the described circumstances.

Additional non-controller upgrade attempts after a failed upgrade can fail during service validation if services are not running. To prevent such upgrade failures you can skip services validation. Pass the option "--skip-tags validation" to the Ansible invocation. 

For example:
upgrade-non-controller.sh --upgrade compute-0 --ansible-opts "--skip-tags validation"

Additional non-controller upgrade attempts after a failed upgrade can fail during service validation if services are not running. To prevent such upgrade failures you can skip services validation. Pass the option "--skip-tags validation" to the Ansible invocation. 

For example:
upgrade-non-controller.sh --upgrade compute-0 --ansible-opts "--skip-tags validation"

TripleO uses ceph-ansible to configure Ceph clients and servers. 
To reduce the undercloud memory requirement when deploying a large number of Compute nodes, the TripleO ceph-ansible fork count default was reduced from 50 to 25.

One result of the lower fork count is a reduction in the number of hosts that can be configured in parallel.

You can use a Heat environment file to override the default fork count. The following example sets the fork count to 10.

parameter_defaults:
CephAnsibleEnvironmentVariables:
DEFAULT_FORKS: '10'

TripleO uses ceph-ansible to configure Ceph clients and servers. 
To reduce the undercloud memory requirement when deploying a large number of Compute nodes, the TripleO ceph-ansible fork count default was reduced from 50 to 25.

One result of the lower fork count is a reduction in the number of hosts that can be configured in parallel.

You can use a Heat environment file to override the default fork count. The following example sets the fork count to 10.

parameter_defaults:
CephAnsibleEnvironmentVariables:
DEFAULT_FORKS: '10'

The TripleO Derived Parameters workflow now searches for nodes in either the 'active' or 'available' states. The TripleO Derived Parameters feature searches for overcloud nodes associated with each TripleO role. 

Previously, the search was limited to nodes in the 'available' state.

After the initial deployment, when nodes are typically in the 'active' state, stack updates failed because the Derived Parameters workflow did not find any nodes in the 'available' state.

The TripleO Derived Parameters workflow now searches for nodes in either the 'active' or 'available' states. The TripleO Derived Parameters feature searches for overcloud nodes associated with each TripleO role. 

Previously, the search was limited to nodes in the 'available' state.

After the initial deployment, when nodes are typically in the 'active' state, stack updates failed because the Derived Parameters workflow did not find any nodes in the 'available' state.

The Derived Parameters workflow now supports the use of SchedulerHints to identify overcloud nodes.

Previously, the workflow could not use use SchedulerHints parameters to identify overcloud nodes associated with the corresponding TripleO overcloud role. This caused the overcloud deployment to fail. 

SchedulerHints support prevents these failures.

The Derived Parameters workflow now supports the use of SchedulerHints to identify overcloud nodes.

Previously, the workflow could not use use SchedulerHints parameters to identify overcloud nodes associated with the corresponding TripleO overcloud role. This caused the overcloud deployment to fail. 

SchedulerHints support prevents these failures.

Connectivity problems that occurred after OSP11-to-OSP12 upgrades have been resolved by the removal of an obsolete network configuration file.

The file was /usr/libexec/os-apply-config/templates/etc/os-net-config/config.json. Its presence on post-upgrade systems caused connectivity problems after a reboot on any overcloud node. Interfaces set under OVS bridges had no connectivity. For example, controller nodes were unable to rejoin the pacemaker cluster.

The upgrade process now removes the file and prevents the connectivity problems.

Connectivity problems that occurred after OSP11-to-OSP12 upgrades have been resolved by the removal of an obsolete network configuration file.

The file was /usr/libexec/os-apply-config/templates/etc/os-net-config/config.json. Its presence on post-upgrade systems caused connectivity problems after a reboot on any overcloud node. Interfaces set under OVS bridges had no connectivity. For example, controller nodes were unable to rejoin the pacemaker cluster.

The upgrade process now removes the file and prevents the connectivity problems.

The file driver for Gnocchi now works as expected in containerized installations. Previously the host directory was not mounted in the container.

Database credentials are no longer logged when a transient container initializes the MySQL database on disk during a fresh overcloud deployment.

Logging verbosity was limited to prevent the logging of database credentials in the container's logs and in the journal.

Database credentials are no longer logged when a transient container initializes the MySQL database on disk during a fresh overcloud deployment.

Logging verbosity was limited to prevent the logging of database credentials in the container's logs and in the journal.

A change in the libvirtd live-migration port range prevents live migration failures.

Previously, libvirtd live-migration used ports 49152 to 49215,as specified in the qemu.conf file. 
On Linux, this range is a subset of the ephemeral port range 32768 to 61000. Any port in the ephemeral range can be consumed by any other service as well. 

As a result, live-migration failed with the error:
Live Migration failure: internal error: Unable to find an unused
port in range 'migration' (49152-49215)

The new libvirtd live-migration range of 61152-61215 is not in the ephemeral range. The related failures no longer occur.

This completes the port change work started in BZ1573791.

A change in the libvirtd live-migration port range prevents live migration failures.

Previously, libvirtd live-migration used ports 49152 to 49215,as specified in the qemu.conf file. 
On Linux, this range is a subset of the ephemeral port range 32768 to 61000. Any port in the ephemeral range can be consumed by any other service as well. 

As a result, live-migration failed with the error:
Live Migration failure: internal error: Unable to find an unused
port in range 'migration' (49152-49215)

The new libvirtd live-migration range of 61152-61215 is not in the ephemeral range. The related failures no longer occur.

This completes the port change work started in BZ1573791.

An error in the NovaSchedulerLoggingSource variable in the puppet/services/nova-conductor.yaml file has been corrected to properly update logs during fluentd configuration.

Previously, nova-scheduler.log was tailed twice and nova-conductor.log was not tailed at all.

An error in the NovaSchedulerLoggingSource variable in the puppet/services/nova-conductor.yaml file has been corrected to properly update logs during fluentd configuration.

Previously, nova-scheduler.log was tailed twice and nova-conductor.log was not tailed at all.

To prevent failures caused by a gnocchi-upgrade race condition, gnocchi-upgrade is now called from the bootstrap node instead of from multiple nodes.

Previously, gnocchi-upgrade was called from each node where gnocchi-api is part of the role. This sometimes resulted in failures with the error shown in the following example:
2018-03-14 12:39:39,683 [1] ERROR oslo_db.sqlalchemy.exc_filters: DBAPIError exception wrapped from (pymysql.err.InternalError) (1050, u"Table 'archive_policy' already exists")

To prevent failures caused by a gnocchi-upgrade race condition, gnocchi-upgrade is now called from the bootstrap node instead of from multiple nodes.

Previously, gnocchi-upgrade was called from each node where gnocchi-api is part of the role. This sometimes resulted in failures with the error shown in the following example:
2018-03-14 12:39:39,683 [1] ERROR oslo_db.sqlalchemy.exc_filters: DBAPIError exception wrapped from (pymysql.err.InternalError) (1050, u"Table 'archive_policy' already exists")

Prior to this update, when removing the ceph-osd RPM from overcloud nodes that do not require the package, the corresponding Ceph OSD product key was not removed. Consequently, the subscription-manager would incorrectly report that the Ceph OSD product was still installed. 

With this update, the script that handles removal of the ceph-osd RPM now also removes the Ceph OSD product key. As a result, after removing the ceph-osd RPM, the subscription-manager no longer errononeously reports the Ceph OSD product is installed.

Note: The script that removes the RPM and product key executes only during the overcloud update procedure.

Prior to this update, when removing the ceph-osd RPM from overcloud nodes that do not require the package, the corresponding Ceph OSD product key was not removed. Consequently, the subscription-manager would incorrectly report that the Ceph OSD product was still installed. 

With this update, the script that handles removal of the ceph-osd RPM now also removes the Ceph OSD product key. As a result, after removing the ceph-osd RPM, the subscription-manager no longer errononeously reports the Ceph OSD product is installed.

Note: The script that removes the RPM and product key executes only during the overcloud update procedure.

OpenStack Director 13 can now successfully deploy an overcloud together with Ceph, using OpenStack 12 templates.

Prior to this update, Ceph deployment would fail during overcloud deployment step 2 because OpenStack Director failed to set the correct version of Ceph. Now OpenStack Director 12 templates always deploy the Ceph Jewel release.

OpenStack Director 13 can now successfully deploy an overcloud together with Ceph, using OpenStack 12 templates.

Prior to this update, Ceph deployment would fail during overcloud deployment step 2 because OpenStack Director failed to set the correct version of Ceph. Now OpenStack Director 12 templates always deploy the Ceph Jewel release.

This update adds the environment file /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml for OVS-DPDK deployments (for new installations and minor updates).

Note: This environment file updates the parameter only for ComputeOvsDpdk role. If any other custom role is used with OvS-DPDK then the environment file should be extended to those custom roles as well.

This update adds the environment file /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml for OVS-DPDK deployments (for new installations and minor updates).

Note: This environment file updates the parameter only for ComputeOvsDpdk role. If any other custom role is used with OvS-DPDK then the environment file should be extended to those custom roles as well.

This update helps operators locate log files after an upgrade from a non-containerized to a containerized deployment.

If old log files are present when the upgrade begins, a readme.txt file is placed in the old file location. The file points to the new log file location.

For example, if a /var/log/nova directory exists, a /var/log/nova/readme.txt file is created, advising the reader to look in the /var/log/containers/nova directory instead.

This update helps operators locate log files after an upgrade from a non-containerized to a containerized deployment.

If old log files are present when the upgrade begins, a readme.txt file is placed in the old file location. The file points to the new log file location.

For example, if a /var/log/nova directory exists, a /var/log/nova/readme.txt file is created, advising the reader to look in the /var/log/containers/nova directory instead.

This update adds the service OS::TripleO::Services::NovaMigrationTarget to the service list of the ComputeOvsDpdk role in the roles_data.yaml. Prior to this update, the omission of the service caused Nova live migration to fail on the ComputeOvsDpdk roles. 

Before starting a minor update, ensure the service is present in the ComputeOvsDpdk role of the roles_data.yaml file.

This update adds the service OS::TripleO::Services::NovaMigrationTarget to the service list of the ComputeOvsDpdk role in the roles_data.yaml. Prior to this update, the omission of the service caused Nova live migration to fail on the ComputeOvsDpdk roles. 

Before starting a minor update, ensure the service is present in the ComputeOvsDpdk role of the roles_data.yaml file.

This change allows TripleO to deploy Cinder with a Dell EMC VNX backend.

The TripleO environment files used for deploying Cinder's Netapp backend have been updated in this release to allow successful deployment of a Cinder Netapp backend. 

Prior to this update, obsolete data caused the overcloud deployment to fail.

The TripleO environment files used for deploying Cinder's Netapp backend have been updated in this release to allow successful deployment of a Cinder Netapp backend. 

Prior to this update, obsolete data caused the overcloud deployment to fail.

The default age for purging deleted database records has been corrected so that deleted records are purged from Cinder's database.

Previously, the CinderCronDbPurgeAge value for Cinder's purge cron job used the wrong value and deleted records were not purged from Cinder's database when they reached the desired default age.

The default age for purging deleted database records has been corrected so that deleted records are purged from Cinder's database.

Previously, the CinderCronDbPurgeAge value for Cinder's purge cron job used the wrong value and deleted records were not purged from Cinder's database when they reached the desired default age.

To enable the neutron-lbaas dashboard:

1. Enable the dashboard in the Horizon configuration file in all controller nodes:
File: /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings

OPENSTACK_NEUTRON_NETWORK = {
'enable_distributed_router': False,
'enable_firewall': False,
'enable_ha_router': False,
'enable_lb': True, <----------

2. Restart the horizon container:
# docker restart horizon

A new "Load Balancers" tab will appear under the "Network" menu. The URL is http://<controller-vip>/dashboard/project/ngloadbalancersv2

To enable the neutron-lbaas dashboard:

1. Enable the dashboard in the Horizon configuration file in all controller nodes:
File: /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings

OPENSTACK_NEUTRON_NETWORK = {
'enable_distributed_router': False,
'enable_firewall': False,
'enable_ha_router': False,
'enable_lb': True, <----------

2. Restart the horizon container:
# docker restart horizon

A new "Load Balancers" tab will appear under the "Network" menu. The URL is http://<controller-vip>/dashboard/project/ngloadbalancersv2

Nova's libvirt driver now allows the specification of granular CPU feature flags when configuring CPU models.  

One benefit of this change is the alleviation of a performance degradation that has been experienced on guests running with certain Intel-based virtual CPU models after application of the "Meltdown" CVE fixes. This guest performance impact is reduced by exposing the CPU feature flag 'PCID' ("Process-Context ID") to the *guest* CPU, assuming that the PCID flag is available in the physical hardware itself.

For more details, refer to the documentation of ``[libvirt]/cpu_model_extra_flags`` in the ``nova.conf`` file for usage details.

Nova's libvirt driver now allows the specification of granular CPU feature flags when configuring CPU models.  

One benefit of this change is the alleviation of a performance degradation that has been experienced on guests running with certain Intel-based virtual CPU models after application of the "Meltdown" CVE fixes. This guest performance impact is reduced by exposing the CPU feature flag 'PCID' ("Process-Context ID") to the *guest* CPU, assuming that the PCID flag is available in the physical hardware itself.

For more details, refer to the documentation of ``[libvirt]/cpu_model_extra_flags`` in the ``nova.conf`` file for usage details.

Prior to this update, running a "stack update" operation on an existing stack to reassess the state of Heat resources caused a failure in container docker-puppet-rabbitmq. This failure prevented users from running stack update operations.

This update fixes the issue by changing the way puppet configuration is done in the rabbitmq container docker-puppet-rabbitmq.

Prior to this update, running a "stack update" operation on an existing stack to reassess the state of Heat resources caused a failure in container docker-puppet-rabbitmq. This failure prevented users from running stack update operations.

This update fixes the issue by changing the way puppet configuration is done in the rabbitmq container docker-puppet-rabbitmq.

This update allows a non-containerized OpenStack service to connect to the Ceph cluster.

Prior to this update, any non-containerized OpenStack service failed to connect to the Ceph cluster because
the file ACLs mask set on the CephX keyrings blocked read permissions for non-containerized OpenStack services.

Puppet now sets the file ACLs mask for the CephX keyrings so that it is allowed to grant read permissions to specific users.

This update allows a non-containerized OpenStack service to connect to the Ceph cluster.

Prior to this update, any non-containerized OpenStack service failed to connect to the Ceph cluster because
the file ACLs mask set on the CephX keyrings blocked read permissions for non-containerized OpenStack services.

Puppet now sets the file ACLs mask for the CephX keyrings so that it is allowed to grant read permissions to specific users.

This fix prevents a potential failure of ceilometer-upgrade during an OpenStack upgrade.

Prior to this fix, the ceilometer-upgrade sometimes failed during an OSP11-OSP12 upgrade because it ran before gnocchi-upgrade.

If you upgraded to OSP12 without this fix and ceilometer-upgrade failed, delete the /etc/gnocchi/gnocchi.conf file from the bootstrap node and re-run the upgrade process with the fixed package.

This fix prevents a potential failure of ceilometer-upgrade during an OpenStack upgrade.

Prior to this fix, the ceilometer-upgrade sometimes failed during an OSP11-OSP12 upgrade because it ran before gnocchi-upgrade.

If you upgraded to OSP12 without this fix and ceilometer-upgrade failed, delete the /etc/gnocchi/gnocchi.conf file from the bootstrap node and re-run the upgrade process with the fixed package.

This update fixes an issue that prevented users from configuring Netapp NFS mount options via the TripleO Heat parameter.

Prior to this update, the Cinder Netapp backend ignored the CinderNetappNfsMountOptions TripleO Heat parameter, preventing configuration of the Netapp NFS mount options via the TripleO Heat parameter.

The code responsible for handling Cinder's Netapp configuration no longer ignores the CinderNetappNfsMountOptions parameter. The CinderNetappNfsMountOptions parameter correctly configures Cinder's Netapp NFS mount options.

This update fixes an issue that prevented users from configuring Netapp NFS mount options via the TripleO Heat parameter.

Prior to this update, the Cinder Netapp backend ignored the CinderNetappNfsMountOptions TripleO Heat parameter, preventing configuration of the Netapp NFS mount options via the TripleO Heat parameter.

The code responsible for handling Cinder's Netapp configuration no longer ignores the CinderNetappNfsMountOptions parameter. The CinderNetappNfsMountOptions parameter correctly configures Cinder's Netapp NFS mount options.

During a version upgrade, Cinder's database synchronization is now executed only on the bootstrap node. This prevents database synchronization and upgrade failures that occurred when database synchronization was executed on all Controller nodes.

OS-Brick FC host bus adapter (HBA) scans have been limited to prevent the addition of unwanted devices.

Previously, the OS-Brick FC code always scanned all present HBAs.

Now the following limits apply:
--If an initiator map is present, only the mapped HBAs are scanned
--In the case of a single WWNN for all ports, only the connected HBAs are scanned
--Else, all HBAs are scanned with wildcards

OS-Brick FC host bus adapter (HBA) scans have been limited to prevent the addition of unwanted devices.

Previously, the OS-Brick FC code always scanned all present HBAs.

Now the following limits apply:
--If an initiator map is present, only the mapped HBAs are scanned
--In the case of a single WWNN for all ports, only the connected HBAs are scanned
--Else, all HBAs are scanned with wildcards

Virtual CPUs (vCPUs) can be preempted by the hypervisor kernel thread even with strong partitioning in place (isolcpus, tuned). Preemptions are not frequent, a few per second, but with 256 descriptors per virtio queue, just one preemption of the vCPU can lead to packet drop, because the 256 slots are filled during the preemption. This is the case for network functions virtualization (NFV) VMs in which the per queue packet rate is above 1 Mpps (1 million packets per second).

This release supports two new tunable options: 'rx_queue_size' and 'tx_queue_size'. Use these options to configure the RX queue size and TX queue size of virtio NICs, respectively, to reduce packet drop.

Virtual CPUs (vCPUs) can be preempted by the hypervisor kernel thread even with strong partitioning in place (isolcpus, tuned). Preemptions are not frequent, a few per second, but with 256 descriptors per virtio queue, just one preemption of the vCPU can lead to packet drop, because the 256 slots are filled during the preemption. This is the case for network functions virtualization (NFV) VMs in which the per queue packet rate is above 1 Mpps (1 million packets per second).

This release supports two new tunable options: 'rx_queue_size' and 'tx_queue_size'. Use these options to configure the RX queue size and TX queue size of virtio NICs, respectively, to reduce packet drop.

Previously, the ability to set an admin password to the metadata service was not implemented for the libvirt driver causing the 'nova get-password' command to return nothing.

This release enables setting an admin password to the metadata service for the libvirt driver. The admin password is saved to the metadata service, and the 'nova get-password' command returns that password.

Previously, the ability to set an admin password to the metadata service was not implemented for the libvirt driver causing the 'nova get-password' command to return nothing.

This release enables setting an admin password to the metadata service for the libvirt driver. The admin password is saved to the metadata service, and the 'nova get-password' command returns that password.

This update slows the initial stages of live migrations to eliminate packet loss. Previously, instances with LinuxBridge VIFs experienced packet loss during live migration. Neutron did not have enough time to complete the plugging of the VIFs and related networking infrastructure on the destination during live migration.

Live migrations are now initially slowed to ensure Neutron has adequate time to wire up the VIFs on the destination. Once complete, Neutron sends an event to Nova, returning the migration to full speed. This requires Neutron 11.0.4 or greater on Pike when used with LinuxBridge VIFs to pick up the Icb039ae2d465e3822ab07ae4f9bc405c1362afba bugfix.

This update slows the initial stages of live migrations to eliminate packet loss. Previously, instances with LinuxBridge VIFs experienced packet loss during live migration. Neutron did not have enough time to complete the plugging of the VIFs and related networking infrastructure on the destination during live migration.

Live migrations are now initially slowed to ensure Neutron has adequate time to wire up the VIFs on the destination. Once complete, Neutron sends an event to Nova, returning the migration to full speed. This requires Neutron 11.0.4 or greater on Pike when used with LinuxBridge VIFs to pick up the Icb039ae2d465e3822ab07ae4f9bc405c1362afba bugfix.

Prior to this update, to re-discover a compute node record after deleting a host mapping from the API database, the compute node record had to be manually marked as unmapped. Otherwise, a compute node with the same hostname could not be mapped back to the cell from which it was removed. 

With this update, the compute node record is automatically marked as unmapped when you delete a host from a cell, enabling a compute node with the same hostname to be added to the cell during host discovery.

Prior to this update, to re-discover a compute node record after deleting a host mapping from the API database, the compute node record had to be manually marked as unmapped. Otherwise, a compute node with the same hostname could not be mapped back to the cell from which it was removed. 

With this update, the compute node record is automatically marked as unmapped when you delete a host from a cell, enabling a compute node with the same hostname to be added to the cell during host discovery.

This update prevents CPU pinning mismatches during Nova live migrations. 

Prior to the update, the scheduler did not check whether the guest CPU pinning configuration was supported on the host. A mismatch of CPU pinning caused errors during bootup of the the host. This failed scenario could be repeated over a series of potential hosts.

A new condition in the NUMATopologyFilter filter identifies hosts with proper CPU pinning capability. If no suitable hosts are available, the migration fails quickly with an error message.

This update prevents CPU pinning mismatches during Nova live migrations. 

Prior to the update, the scheduler did not check whether the guest CPU pinning configuration was supported on the host. A mismatch of CPU pinning caused errors during bootup of the the host. This failed scenario could be repeated over a series of potential hosts.

A new condition in the NUMATopologyFilter filter identifies hosts with proper CPU pinning capability. If no suitable hosts are available, the migration fails quickly with an error message.

This update prevents an unintended bypass of the schedule filters This update prevents an unintended bypass of the schedule filters that could occur after the scheduler refused a rebuild request sent by nova.

If a user rebuilds an instance with a new image, the change from old image to new image causes nova to send the rebuild request to the scheduler to make sure it is allowed according to the scheduler filters. 

Prior to this update, if the scheduler refused the request, the instance's image reference was not rolled back to the original image. This caused an inconsistency between the original image actually in use by the instance, and the new image reference saved in the database. As a result, a second rebuild request with the same new image would bypass the scheduler and be allowed, because the image in the rebuild request was the same as the instance's image in the database, even though the real image in use by the instance was the old original image. This bypass of scheduler filters was considered a security flaw.

As of this update, when a rebuild request is refused by the scheduler,the image reference is rolled back to the original. If another rebuild request is made with the same new image, it is correctly identified as being different from the instance's current image and the request is send to the scheduler.

This update prevents an unintended bypass of the schedule filters This update prevents an unintended bypass of the schedule filters that could occur after the scheduler refused a rebuild request sent by nova.

If a user rebuilds an instance with a new image, the change from old image to new image causes nova to send the rebuild request to the scheduler to make sure it is allowed according to the scheduler filters. 

Prior to this update, if the scheduler refused the request, the instance's image reference was not rolled back to the original image. This caused an inconsistency between the original image actually in use by the instance, and the new image reference saved in the database. As a result, a second rebuild request with the same new image would bypass the scheduler and be allowed, because the image in the rebuild request was the same as the instance's image in the database, even though the real image in use by the instance was the old original image. This bypass of scheduler filters was considered a security flaw.

As of this update, when a rebuild request is refused by the scheduler,the image reference is rolled back to the original. If another rebuild request is made with the same new image, it is correctly identified as being different from the instance's current image and the request is send to the scheduler.

Prior to this update, a volume detach operation performed under certain failure scenarios could result in the removal of a volume's libvirt definition without full removal of the associated logical volume (LUN) from the host. This allowed Cinder to incorrectly perform subsequent operations while the compute host still had active paths to the device.

As of this update, even under a failure scenario, Nova compute attempts to disconnect the LUN from the host. The result is a better release of the logical volume on the host.

Prior to this update, a volume detach operation performed under certain failure scenarios could result in the removal of a volume's libvirt definition without full removal of the associated logical volume (LUN) from the host. This allowed Cinder to incorrectly perform subsequent operations while the compute host still had active paths to the device.

As of this update, even under a failure scenario, Nova compute attempts to disconnect the LUN from the host. The result is a better release of the logical volume on the host.

Channel	Repository Name
Red Hat Enterprise Linux 7 Server (RPMS)	`rhel-7-server-rpms`
Red Hat Enterprise Linux 7 Server - RH Common (RPMs)	`rhel-7-server-rh-common-rpms`
Red Hat Enterprise Linux High Availability (for RHEL 7 Server)	`rhel-ha-for-rhel-7-server-rpms`
Red Hat OpenStack Platform 12 for RHEL 7 (RPMs)	`rhel-7-server-openstack-12-rpms`
Red Hat Enterprise Linux 7 Server - Extras (RPMs)	`rhel-7-server-extras-rpms`

Channel	Repository Name
Red Hat Enterprise Linux 7 Server - Optional	`rhel-7-server-optional-rpms`
Red Hat OpenStack Platform 12 Operational Tools for RHEL 7 (RPMs)	`rhel-7-server-openstack-12-optools-rpms`

Channel	Repository Name
Red Hat Enterprise Linux for IBM Power, little endian	`rhel-7-for-power-le-rpms`
Red Hat OpenStack Platform 12 for RHEL 7 (RPMs)	`rhel-7-server-openstack-12-for-power-le-rpms`

Channel	Repository Name
Red Hat CloudForms Management Engine	`"cf-me-*"`
Red Hat Enterprise Virtualization	`"rhel-7-server-rhev*"`
Red Hat Enterprise Linux 7 Server - Extended Update Support	`"*-eus-rpms"`

Release Notes

Release details for Red Hat OpenStack Platform 12

OpenStack Documentation Team

Chapter 1. IntroductionCopy linkLink copied to clipboard!

1.1. About this ReleaseCopy linkLink copied to clipboard!

1.2. RequirementsCopy linkLink copied to clipboard!

1.3. Deployment LimitsCopy linkLink copied to clipboard!

1.4. Database Size ManagementCopy linkLink copied to clipboard!

1.5. Certified Drivers and Plug-insCopy linkLink copied to clipboard!

1.6. Certified Guest Operating SystemsCopy linkLink copied to clipboard!

1.7. Bare Metal Provisioning Supported Operating SystemsCopy linkLink copied to clipboard!

1.8. Hypervisor SupportCopy linkLink copied to clipboard!

1.9. Content Delivery Network (CDN) ChannelsCopy linkLink copied to clipboard!

1.10. Product SupportCopy linkLink copied to clipboard!

1.11. Key Changes to the Documentation SetCopy linkLink copied to clipboard!

Chapter 2. Top New FeaturesCopy linkLink copied to clipboard!

2.1. Red Hat OpenStack Platform DirectorCopy linkLink copied to clipboard!

2.2. ContainersCopy linkLink copied to clipboard!

2.3. Bare Metal ServiceCopy linkLink copied to clipboard!

2.4. Block StorageCopy linkLink copied to clipboard!

2.5. Ceph StorageCopy linkLink copied to clipboard!

2.6. ComputeCopy linkLink copied to clipboard!

2.7. High AvailabilityCopy linkLink copied to clipboard!

2.8. IdentityCopy linkLink copied to clipboard!

2.9. Network Functions VirtualizationCopy linkLink copied to clipboard!

2.10. Object StorageCopy linkLink copied to clipboard!

2.11. OpenDaylight (Technology Preview)Copy linkLink copied to clipboard!

2.12. OpenStack Data Processing ServiceCopy linkLink copied to clipboard!

2.13. OpenStack NetworkingCopy linkLink copied to clipboard!

2.14. Operations ToolingCopy linkLink copied to clipboard!

2.15. Shared File SystemCopy linkLink copied to clipboard!

2.16. TelemetryCopy linkLink copied to clipboard!

2.17. Technology PreviewsCopy linkLink copied to clipboard!

2.17.1. New Technology PreviewsCopy linkLink copied to clipboard!

2.17.2. Previously Released Technology PreviewsCopy linkLink copied to clipboard!

Chapter 3. Release InformationCopy linkLink copied to clipboard!

3.1. Red Hat OpenStack Platform 12 GACopy linkLink copied to clipboard!

3.1.1. EnhancementsCopy linkLink copied to clipboard!

3.1.2. Technology PreviewCopy linkLink copied to clipboard!

3.1.3. Release NotesCopy linkLink copied to clipboard!

3.1.4. Known IssuesCopy linkLink copied to clipboard!

3.1.5. Deprecated FunctionalityCopy linkLink copied to clipboard!

3.2. Red Hat OpenStack Platform 12 Maintenance Release January 2018Copy linkLink copied to clipboard!

3.2.1. Known IssuesCopy linkLink copied to clipboard!

3.3. Red Hat OpenStack Platform 12 Maintenance Release 28 March 2018Copy linkLink copied to clipboard!

3.3.1. Release NotesCopy linkLink copied to clipboard!

3.3.2. Known IssuesCopy linkLink copied to clipboard!

3.4. Red Hat OpenStack Platform 12 Maintenance Release 20 August 2018Copy linkLink copied to clipboard!

3.4.1. EnhancementsCopy linkLink copied to clipboard!

3.4.2. Release NotesCopy linkLink copied to clipboard!

3.4.3. Known IssuesCopy linkLink copied to clipboard!

3.5. Red Hat OpenStack Platform 12 Maintenance Release 5 December 2018Copy linkLink copied to clipboard!

3.5.1. End of LifeCopy linkLink copied to clipboard!

Chapter 4. Technical NotesCopy linkLink copied to clipboard!

4.1. RHEA-2017:3462 — Red Hat OpenStack Platform 12.0 Enhancement AdvisoryCopy linkLink copied to clipboard!

4.2. RHEA-2018:2331 — Red Hat OpenStack Platform 12.0 Enhancement Advisory August 2018Copy linkLink copied to clipboard!

4.3. RHEA-2018:2332 — Red Hat OpenStack Platform 12.0 Security Advisory August 2018Copy linkLink copied to clipboard!

Legal NoticeCopy linkLink copied to clipboard!

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapter 1. Introduction
Copy link

1.1. About this Release
Copy link

1.2. Requirements
Copy link

1.3. Deployment Limits
Copy link

1.4. Database Size Management
Copy link

1.5. Certified Drivers and Plug-ins
Copy link

1.6. Certified Guest Operating Systems
Copy link

1.7. Bare Metal Provisioning Supported Operating Systems
Copy link

1.8. Hypervisor Support
Copy link

1.9. Content Delivery Network (CDN) Channels
Copy link

1.10. Product Support
Copy link

1.11. Key Changes to the Documentation Set
Copy link

Chapter 2. Top New Features
Copy link

2.1. Red Hat OpenStack Platform Director
Copy link

2.2. Containers
Copy link

2.3. Bare Metal Service
Copy link

2.4. Block Storage
Copy link

2.5. Ceph Storage
Copy link

2.6. Compute
Copy link

2.7. High Availability
Copy link

2.8. Identity
Copy link

2.9. Network Functions Virtualization
Copy link

2.10. Object Storage
Copy link

2.11. OpenDaylight (Technology Preview)
Copy link

2.12. OpenStack Data Processing Service
Copy link

2.13. OpenStack Networking
Copy link

2.14. Operations Tooling
Copy link

2.15. Shared File System
Copy link

2.16. Telemetry
Copy link

2.17. Technology Previews
Copy link

2.17.1. New Technology Previews
Copy link

2.17.2. Previously Released Technology Previews
Copy link

Chapter 3. Release Information
Copy link

3.1. Red Hat OpenStack Platform 12 GA
Copy link

3.1.1. Enhancements
Copy link

3.1.2. Technology Preview
Copy link

3.1.3. Release Notes
Copy link

3.1.4. Known Issues
Copy link

3.1.5. Deprecated Functionality
Copy link

3.2. Red Hat OpenStack Platform 12 Maintenance Release January 2018
Copy link

3.2.1. Known Issues
Copy link

3.3. Red Hat OpenStack Platform 12 Maintenance Release 28 March 2018
Copy link

3.3.1. Release Notes
Copy link

3.3.2. Known Issues
Copy link

3.4. Red Hat OpenStack Platform 12 Maintenance Release 20 August 2018
Copy link

3.4.1. Enhancements
Copy link

3.4.2. Release Notes
Copy link

3.4.3. Known Issues
Copy link

3.5. Red Hat OpenStack Platform 12 Maintenance Release 5 December 2018
Copy link

3.5.1. End of Life
Copy link

Chapter 4. Technical Notes
Copy link

4.1. RHEA-2017:3462 — Red Hat OpenStack Platform 12.0 Enhancement Advisory
Copy link

4.2. RHEA-2018:2331 — Red Hat OpenStack Platform 12.0 Enhancement Advisory August 2018
Copy link

4.3. RHEA-2018:2332 — Red Hat OpenStack Platform 12.0 Security Advisory August 2018
Copy link

Legal Notice
Copy link