Chapter 4. Technical Notes

Previously, the Satellite URL was not correctly set in the role. This prevented the system from getting the Satellite server version, and registration failed. This fix adds the capability to get the rhsm_satellite_url value from the rhsm_baseurl parameter by default, passes the URL to the registration task to allow force registration, and adds the option to ignore certificate errors. You can override the default value or configure the options as needed.

Previously, the Satellite URL was not correctly set in the role. This prevented the system from getting the Satellite server version, and registration failed. This fix adds the capability to get the rhsm_satellite_url value from the rhsm_baseurl parameter by default, passes the URL to the registration task to allow force registration, and adds the option to ignore certificate errors. You can override the default value or configure the options as needed.

OpenStack Rally, previously included as a technical preview, is removed from this release.

OpenStack Rally, previously included as a technical preview, is removed from this release.

With this update, the aodh service now validates event type input queries.
Prior to this update, input queries were not validated. An invalid input query could result in the failure to issue an alarm.

With this update, the aodh service now validates event type input queries.
Prior to this update, input queries were not validated. An invalid input query could result in the failure to issue an alarm.

Instance resources have three new attributes: launched_at, deleted_at, created_at to track the exact time that Nova creates/launches/deletes instances.

Instance resources have three new attributes: launched_at, deleted_at, created_at to track the exact time that Nova creates/launches/deletes instances.

The OpenStack Metrics service (Ceilometer) created metrics that were not measured by the Monitoring service (Gnocchi). This fix removes the unnecessary metrics. Now, Ceilometer creates only metrics that will be measured by Gnocchi.

The OpenStack Metrics service (Ceilometer) created metrics that were not measured by the Monitoring service (Gnocchi). This fix removes the unnecessary metrics. Now, Ceilometer creates only metrics that will be measured by Gnocchi.

This release adds a Technology Preview of the ability to attach a volume to multiple hosts or servers simultaneously in both cinder and nova with read/write (RW) mode when this feature is supported by the back end driver. This feature addresses the clustered application workloads use case that typically requires active/active or active/standby scenarios.

This release adds a Technology Preview of the ability to attach a volume to multiple hosts or servers simultaneously in both cinder and nova with read/write (RW) mode when this feature is supported by the back end driver. This feature addresses the clustered application workloads use case that typically requires active/active or active/standby scenarios.

This enhancement optimizes migration of an RBD volume from one Cinder back end to another when the volume resides within the same Ceph cluster.  If both volumes are in the same Ceph cluster, data migration is performed by ceph itself, instead of the cinder-volume process. This reduces migration time.

This enhancement optimizes migration of an RBD volume from one Cinder back end to another when the volume resides within the same Ceph cluster.  If both volumes are in the same Ceph cluster, data migration is performed by ceph itself, instead of the cinder-volume process. This reduces migration time.

Some commands from the OpenStack Bare Metal service (Ironic) to BMCs with IPMI hardware failed due to hardware driver errors. This prevented bare metal nodes from booting. This fix adds the ipmi_disable_boot_timeout hardware driver option, which prevents Ironic from sending these commands to IPMI hardware.

Some commands from the OpenStack Bare Metal service (Ironic) to BMCs with IPMI hardware failed due to hardware driver errors. This prevented bare metal nodes from booting. This fix adds the ipmi_disable_boot_timeout hardware driver option, which prevents Ironic from sending these commands to IPMI hardware.

This update fixes UEFI persistent boot mode support for Dell EMC PowerEdge 13th and 14th generation servers. Those servers now successfully boot into the deployed operating system for either persistent boot modes: BIOS and UEFI.
The fix applies to servers managed by the ironic integrated Dell Remote Access Controller (iDRAC) management hardware implementation ('idrac') function, located in ironic.drivers.modules.drac.management.

The bug is not resolved for PowerEdge 12th generation and earlier servers; however, BIOS boot mode continues to be supported in PowerEdge 12th generation and ealier servers.

Prior to this update, the boot device would persist during subsequent reboots only when the server's boot mode was set to BIOS.

This update fixes UEFI persistent boot mode support for Dell EMC PowerEdge 13th and 14th generation servers. Those servers now successfully boot into the deployed operating system for either persistent boot modes: BIOS and UEFI.
The fix applies to servers managed by the ironic integrated Dell Remote Access Controller (iDRAC) management hardware implementation ('idrac') function, located in ironic.drivers.modules.drac.management.

The bug is not resolved for PowerEdge 12th generation and earlier servers; however, BIOS boot mode continues to be supported in PowerEdge 12th generation and ealier servers.

Prior to this update, the boot device would persist during subsequent reboots only when the server's boot mode was set to BIOS.

This update introduces multi-tenant bare metal networking with the "neutron" network interface.

By configuring the bare metal nodes with the "neutron" network interface, an operator can enable the users to use isolated VLAN networks for provisioning and tenant traffic on bare metal nodes.

This update introduces multi-tenant bare metal networking with the "neutron" network interface.

By configuring the bare metal nodes with the "neutron" network interface, an operator can enable the users to use isolated VLAN networks for provisioning and tenant traffic on bare metal nodes.

In prior releases, a race condition existed in the ironic-conductor hash ring code. A hash ring can be None under load, but this causes an internal server error: 'NoneType' object has no attribute 'getitem_'. This release fixes the race condition, and ironic API operations no longer fail with 'NoneType' object has no attribute 'getitem_'.

In prior releases, a race condition existed in the ironic-conductor hash ring code. A hash ring can be None under load, but this causes an internal server error: 'NoneType' object has no attribute 'getitem_'. This release fixes the race condition, and ironic API operations no longer fail with 'NoneType' object has no attribute 'getitem_'.

With this update, Users can create application credentials to allow their applications to authenticate to keystone.

See https://docs.openstack.org/keystone/latest/user/application_credentials.html

With this update, Users can create application credentials to allow their applications to authenticate to keystone.

See https://docs.openstack.org/keystone/latest/user/application_credentials.html

The OpenStack Dashboard (Horizon) plug-in for Manilla was unable to retrieve project quota information. This prevented the user from creating shares and caused rendering issues in the shared file systems dashboard. After this fix, the retrieval operation works as expected and the users can view shared file systems and create shares in the dashboard.

The OpenStack Dashboard (Horizon) plug-in for Manilla was unable to retrieve project quota information. This prevented the user from creating shares and caused rendering issues in the shared file systems dashboard. After this fix, the retrieval operation works as expected and the users can view shared file systems and create shares in the dashboard.

When using the linuxbridge ml2 driver, non-privileged tenants are able to create and attach ports without specifying an IP address, bypassing IP address validation. A potential Denial of Service could occur if an IP address, conflicting with existing guests or routers, is then assigned from outside of the allowed allocation pool.

When using the linuxbridge ml2 driver, non-privileged tenants are able to create and attach ports without specifying an IP address, bypassing IP address validation. A potential Denial of Service could occur if an IP address, conflicting with existing guests or routers, is then assigned from outside of the allowed allocation pool.

This update supports two new tunable options that can be used 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 update 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.

This update supports two new tunable options that can be used 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 update 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 guest CPU models.

For example, this feature allows to mitigate guests from performance degradation that is caused by running 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 on how to specify granular CPU flags, refer to the  documentation of [libvirt]/cpu_model_extra_flags in nova.conf for usage details.

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

For example, this feature allows to mitigate guests from performance degradation that is caused by running 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 on how to specify granular CPU flags, refer to the  documentation of [libvirt]/cpu_model_extra_flags in nova.conf for usage details.

With this update, the libvirt compute driver now allows users to create instances with trusted SR-IOV virtual functions. When trusted, a VF can perform certain operations, such as modifying the VF’s MAC address in the guest.

Interface bonding requires that all slaves use the same MAC address, which in turn requires MAC address modifications on one of the VFs during a failover. Because MAC address altering is a privileged operation, participating VFs must be trusted in order to successfully configure bonding in the guest.

Administrators can now configure trusted mode for VFs. This requires two steps. First, the 'trusted' value of the '[pci] passthrough_whitelist' JSON configuration option in nova.conf must be set to 'true'. For example:

[pci]
passthrough_whitelist = {"devname": "eth0", "trusted": "true",
                         "physical_network":"sriovnet1"}

Then, when creating the port, 'trusted=true' must be set for the binding profile. For example:

$ neutron port-create <net-id> \
    --name sriov_port \
    --vnic-type direct \
    --binding:profile type=dict trusted=true

Because trusted mode only applies to SR-IOV VFs, the 'vnic-type' must be one of 'hw_veb' or 'direct'.

With this update, the libvirt compute driver now allows users to create instances with trusted SR-IOV virtual functions. When trusted, a VF can perform certain operations, such as modifying the VF’s MAC address in the guest.

Interface bonding requires that all slaves use the same MAC address, which in turn requires MAC address modifications on one of the VFs during a failover. Because MAC address altering is a privileged operation, participating VFs must be trusted in order to successfully configure bonding in the guest.

Administrators can now configure trusted mode for VFs. This requires two steps. First, the 'trusted' value of the '[pci] passthrough_whitelist' JSON configuration option in nova.conf must be set to 'true'. For example:

[pci]
passthrough_whitelist = {"devname": "eth0", "trusted": "true",
                         "physical_network":"sriovnet1"}

Then, when creating the port, 'trusted=true' must be set for the binding profile. For example:

$ neutron port-create <net-id> \
    --name sriov_port \
    --vnic-type direct \
    --binding:profile type=dict trusted=true

Because trusted mode only applies to SR-IOV VFs, the 'vnic-type' must be one of 'hw_veb' or 'direct'.

Feature:
Add the CPUWeigher weigher for nova-scheduler.

Reason:
The CPUWeigher allows operators to configure a stacking or spreading policy for vCPUs.

Result:
Operators can enable the CPUWeigher and configure a stacking (use all vCPUs on one node first) or spreading (attempt to use a roughly equal amount of vCPUs from all hosts) policy.

Feature:
Add the CPUWeigher weigher for nova-scheduler.

Reason:
The CPUWeigher allows operators to configure a stacking or spreading policy for vCPUs.

Result:
Operators can enable the CPUWeigher and configure a stacking (use all vCPUs on one node first) or spreading (attempt to use a roughly equal amount of vCPUs from all hosts) policy.

With this update, Nova screens for the NUMA affinity of host huge pages when booting instances with huge pages. Nova rejects NUMA nodes with insufficient huge pages.

Prior to this update, Nova did not screen for NUMA affinity of huge pages. If the host had insufficient NUMA pages, even with sufficient CPUs, the instance boot would fail.

With this update, Nova screens for the NUMA affinity of host huge pages when booting instances with huge pages. Nova rejects NUMA nodes with insufficient huge pages.

Prior to this update, Nova did not screen for NUMA affinity of huge pages. If the host had insufficient NUMA pages, even with sufficient CPUs, the instance boot would fail.

OpenStack Sahara now supports Cloudera Distribution Hadoop (CDH) plugin 5.13.

OpenStack Sahara now supports Cloudera Distribution Hadoop (CDH) plugin 5.13.

This update adds support of s3-compatible object stores for OpenStack Sahara.

This update adds support of s3-compatible object stores for OpenStack Sahara.

A new tripleo heat template has been added to support QDR.
Enabling the metrics_qdr service deploys QDR service on all overcloud nodes, which will be used for routing metrics data from collectd service running on each overcloud node.

The relevant heat template parameters are shown below.

MetricsQdrPort:
default: '5666'
description: Service name or port number on which the qdrouterd will accept
            connections. This argument must be string, even if the numeric
            form is used.
type: string
MetricsQdrUsername:
default: 'guest'
description: Username which should be used to authenticate to the deployed
            qdrouterd.
type: string
MetricsQdrPassword:
default: 'guest'
description: Password which should be used to authenticate to the deployed
            qdrouterd.
type: string
hidden: true
MetricsQdrConnectors:
default: []
description: Connectors configuration (array of hashes).
type: json
MetricsQdrAddresses:
default:
 - prefix: 'collectd/notify'
   distribution: multicast
 - prefix: 'collectd/telemetry'
   distribution: multicast
description: Addresses configuration (array of hashes).
type: json
MetricsQdrUseSSL:
default: false
description: Set to true if it is required to use SSL or TLS on
            the connection for listener.
type: boolean
MetricsQdrUseEncryption:
default: false
description: Set to true if it is required to encrypt connection to the peer
            for listener.
type: boolean
MetricsQdrSaslMechanisms:
default: 'ANONYMOUS'
description: List of accepted SASL auth mechanisms for listener in format
            of comma separated list.
type: string
MetricsQdrSslCertDb:
default: ''
description: Path to SSL certificate db for listener.
type: string
MetricsQdrSslCertFile:
default: ''
description: Path to SSL certificate file for listener.
type: string
MetricsQdrSslKeyFile:
default: ''
description: Path to SSL private key file for listener.
type: string
MetricsQdrSslPwFile:
default: ''
description: Path to SSL password file for certificate key for listener.
type: string
MetricsQdrSslPassword:
default: ''
description: SSL password to be supplied for listener.
type: string
MetricsQdrTrustedCerts:
default: ''
description: Path to file containing trusted certificates for listener.
type: string

A new tripleo heat template has been added to support QDR.
Enabling the metrics_qdr service deploys QDR service on all overcloud nodes, which will be used for routing metrics data from collectd service running on each overcloud node.

The relevant heat template parameters are shown below.

MetricsQdrPort:
default: '5666'
description: Service name or port number on which the qdrouterd will accept
            connections. This argument must be string, even if the numeric
            form is used.
type: string
MetricsQdrUsername:
default: 'guest'
description: Username which should be used to authenticate to the deployed
            qdrouterd.
type: string
MetricsQdrPassword:
default: 'guest'
description: Password which should be used to authenticate to the deployed
            qdrouterd.
type: string
hidden: true
MetricsQdrConnectors:
default: []
description: Connectors configuration (array of hashes).
type: json
MetricsQdrAddresses:
default:
 - prefix: 'collectd/notify'
   distribution: multicast
 - prefix: 'collectd/telemetry'
   distribution: multicast
description: Addresses configuration (array of hashes).
type: json
MetricsQdrUseSSL:
default: false
description: Set to true if it is required to use SSL or TLS on
            the connection for listener.
type: boolean
MetricsQdrUseEncryption:
default: false
description: Set to true if it is required to encrypt connection to the peer
            for listener.
type: boolean
MetricsQdrSaslMechanisms:
default: 'ANONYMOUS'
description: List of accepted SASL auth mechanisms for listener in format
            of comma separated list.
type: string
MetricsQdrSslCertDb:
default: ''
description: Path to SSL certificate db for listener.
type: string
MetricsQdrSslCertFile:
default: ''
description: Path to SSL certificate file for listener.
type: string
MetricsQdrSslKeyFile:
default: ''
description: Path to SSL private key file for listener.
type: string
MetricsQdrSslPwFile:
default: ''
description: Path to SSL password file for certificate key for listener.
type: string
MetricsQdrSslPassword:
default: ''
description: SSL password to be supplied for listener.
type: string
MetricsQdrTrustedCerts:
default: ''
description: Path to file containing trusted certificates for listener.
type: string

The OvsDpdkMemoryChannels parameter cannot be derived through the DPDK derive parameters workflow. The value is set to 4 by default. You can change that value in your custom environments file to match your hardware.

The OvsDpdkMemoryChannels parameter cannot be derived through the DPDK derive parameters workflow. The value is set to 4 by default. You can change that value in your custom environments file to match your hardware.

Prior to this update, with shared storage for /var/lib/nova/instances, such as nfs, restarting the nova_compute container on any compute node resulted in an owner/group change of the instances virtual ephemeral disks and console.log. As a result, instances lost access to their virtual ephemeral disks and stopped working.
The method to modify the ownership of the instance files in /var/lib/nova/instances have been improved to target only the necessary files/directories.
There is now no loss in access to the instance files during restart of nova compute.

Prior to this update, with shared storage for /var/lib/nova/instances, such as nfs, restarting the nova_compute container on any compute node resulted in an owner/group change of the instances virtual ephemeral disks and console.log. As a result, instances lost access to their virtual ephemeral disks and stopped working.
The method to modify the ownership of the instance files in /var/lib/nova/instances have been improved to target only the necessary files/directories.
There is now no loss in access to the instance files during restart of nova compute.

Dedicated monitor node scale-up or monitor replacement no longer causes the stack update command to fail or to take Ceph monitors out of quorum.

Dedicated monitor node scale-up or monitor replacement no longer causes the stack update command to fail or to take Ceph monitors out of quorum.

After deprecating the instack_undercloud functionality, upgrading the undercloud with an admin user failed with a permission error. This was due to the admin user missing the member role. This fix adds the member role back to the admin user from puppet-keystone module and tripleo-teat-templates.

After deprecating the instack_undercloud functionality, upgrading the undercloud with an admin user failed with a permission error. This was due to the admin user missing the member role. This fix adds the member role back to the admin user from puppet-keystone module and tripleo-teat-templates.

Replacement of Controller nodes with ODL previously failed due to ODL configuration files missing during redeployment. This fix unmounts the /opt/opendaylight/data directory from the host, which then triggers the regeneration of ODL configuration files during the replacement process.

Replacement of Controller nodes with ODL previously failed due to ODL configuration files missing during redeployment. This fix unmounts the /opt/opendaylight/data directory from the host, which then triggers the regeneration of ODL configuration files during the replacement process.

The OpenStack Director previously configured HAProxy load-balancing with roundrobin instead of source balance, which resulted in sticky sessions failures. After this fix, the Director uses source balance for load-balancing in the HAProxy configuration, and sticky sessions run as expected.

The OpenStack Director previously configured HAProxy load-balancing with roundrobin instead of source balance, which resulted in sticky sessions failures. After this fix, the Director uses source balance for load-balancing in the HAProxy configuration, and sticky sessions run as expected.

OpenStack Director previously always used IP addresses for the openshift_master_cluster_hostname and openshift_master_cluster_public_hostname parameters, which caused host names from the OpenShiftGlobalVariables Heat parameter to be ignored. After this fix, the Director will use the host name if provided, and the IP addresses if no host name is provided.

OpenStack Director previously always used IP addresses for the openshift_master_cluster_hostname and openshift_master_cluster_public_hostname parameters, which caused host names from the OpenShiftGlobalVariables Heat parameter to be ignored. After this fix, the Director will use the host name if provided, and the IP addresses if no host name is provided.

With this update, OSP 14 supports setting specific IP addresses for each node in each role when using routed spine-and-leaf networking.

Prior to this update, setting specific IPs for each node was only supported for deployments that do not use routed spine-and-leaf networking. It is possible to set specific IPs for each network in OSP 13, but in OSP 13 this feature was considered Tech Preview due to lack of sufficient documentation and testing.

OSP 14 allows operators to choose which IP addresses to use for each network on each node in each role when using routed spine-and-leaf, including multiple routed subnets in the same network.

With this update, OSP 14 supports setting specific IP addresses for each node in each role when using routed spine-and-leaf networking.

Prior to this update, setting specific IPs for each node was only supported for deployments that do not use routed spine-and-leaf networking. It is possible to set specific IPs for each network in OSP 13, but in OSP 13 this feature was considered Tech Preview due to lack of sufficient documentation and testing.

OSP 14 allows operators to choose which IP addresses to use for each network on each node in each role when using routed spine-and-leaf, including multiple routed subnets in the same network.

With this update, NTP time is synced early in the deployment process to prevent container configuration and deployment failure. If the NTP servers are not accessible and cannot be synced, deployment fails immediately.
Prior to this update, failures could occur later with a cryptic error message.

With this update, NTP time is synced early in the deployment process to prevent container configuration and deployment failure. If the NTP servers are not accessible and cannot be synced, deployment fails immediately.
Prior to this update, failures could occur later with a cryptic error message.

With this enhancement, you can configure collectd to send metrics data to local QPID dispatch router services, to support service assurance framework implementation.

New collectd tripleo heat template parameters let you configure the amqp1 write plugin.
Set the CollectdConnectionType parameter to 'amqp1'.
As a result, all metrics data are sent to the local QDR unless explicitly overridden by the parameters shown below.

To deploy the local QDR, use the environment file /usr/share/openstack-tripleo-heat-templates/environments/metrics-collectd-qdr.yaml.

The relevant heat template parameters are shown below.
CollectdAmqpHost:
type: string
description: Hostname or IP address of the AMQP 1.0 intermediary.
default: nil
CollectdAmqpPort:
type: string
description: >
  Service name or port number on which the AMQP 1.0 intermediary accepts
  connections. This argument must be a string, even if the numeric form
  is used.
default: '5666'
CollectdAmqpUser:
type: string
description: >
  User part of credentials used to authenticate to the AMQP 1.0 intermediary.
default: guest
CollectdAmqpPassword:
type: string
description: >
  Password part of credentials used to authenticate to the AMQP 1.0 intermediary.
default: guest
hidden: true
CollectdAmqpTransportName:
type: string
description: Name of the AMQP 1.0 transport.
default: metrics
CollectdAmqpAddress:
type: string
description: >
  This option specifies the prefix for the send-to value in the message.
default: collectd
CollectdAmqpInstances:
type: json
description: >
  Hash of hashes. Each inner hash represent Instance block in plugin
  configuration file. Key of outer hash represents instance name.
  The 'address' value concatenated with the 'name' given will be used
  as the send-to address for communications over the messaging link.
default: {}
CollectdAmqpRetryDelay:
type: number
description: >
  When the AMQP 1.0 connection is lost, defines the time in seconds to wait
  before attempting to reconnect.
default: 1
CollectdAmqpInterval:
type: number
description: >
  Interval on which metrics should be sent to AMQP intermediary. If not set
  the default for all collectd plugins is used.
default: -666

With this enhancement, you can configure collectd to send metrics data to local QPID dispatch router services, to support service assurance framework implementation.

New collectd tripleo heat template parameters let you configure the amqp1 write plugin.
Set the CollectdConnectionType parameter to 'amqp1'.
As a result, all metrics data are sent to the local QDR unless explicitly overridden by the parameters shown below.

To deploy the local QDR, use the environment file /usr/share/openstack-tripleo-heat-templates/environments/metrics-collectd-qdr.yaml.

The relevant heat template parameters are shown below.
CollectdAmqpHost:
type: string
description: Hostname or IP address of the AMQP 1.0 intermediary.
default: nil
CollectdAmqpPort:
type: string
description: >
  Service name or port number on which the AMQP 1.0 intermediary accepts
  connections. This argument must be a string, even if the numeric form
  is used.
default: '5666'
CollectdAmqpUser:
type: string
description: >
  User part of credentials used to authenticate to the AMQP 1.0 intermediary.
default: guest
CollectdAmqpPassword:
type: string
description: >
  Password part of credentials used to authenticate to the AMQP 1.0 intermediary.
default: guest
hidden: true
CollectdAmqpTransportName:
type: string
description: Name of the AMQP 1.0 transport.
default: metrics
CollectdAmqpAddress:
type: string
description: >
  This option specifies the prefix for the send-to value in the message.
default: collectd
CollectdAmqpInstances:
type: json
description: >
  Hash of hashes. Each inner hash represent Instance block in plugin
  configuration file. Key of outer hash represents instance name.
  The 'address' value concatenated with the 'name' given will be used
  as the send-to address for communications over the messaging link.
default: {}
CollectdAmqpRetryDelay:
type: number
description: >
  When the AMQP 1.0 connection is lost, defines the time in seconds to wait
  before attempting to reconnect.
default: 1
CollectdAmqpInterval:
type: number
description: >
  Interval on which metrics should be sent to AMQP intermediary. If not set
  the default for all collectd plugins is used.
default: -666

In a tls-everywhere scenario for VNC, the following TLS connections exist:

- client -> haproxy
- novncproxy -> vnc server (instance)

However, the connection from haproxy to nova novncproxy was not encrypted, resulting in an unencrypted local connection from haproxy to nova novnc-proxy service on the controller. With this release, the connection from haproxy to nova novnc-proxy service is encrypted.

In a tls-everywhere scenario for VNC, the following TLS connections exist:

- client -> haproxy
- novncproxy -> vnc server (instance)

However, the connection from haproxy to nova novncproxy was not encrypted, resulting in an unencrypted local connection from haproxy to nova novnc-proxy service on the controller. With this release, the connection from haproxy to nova novnc-proxy service is encrypted.

In prior releases, you could set RX/TX queue size via nova::compute::libvirt::rx_queue_size/nova::compute::libvirt::tx_queue_size. However, there was no dedicated TripleO heat template parameter. With this release, the RX/TX queue size can be set on a role base like this:

parameter_defaults:
ComputeParameters:
NovaLibvirtRxQueueSize: 1024
NovaLibvirtTxQueueSize: 1024

The result is rx_queue_size/tx_queue_size is set using new parameters.

In prior releases, you could set RX/TX queue size via nova::compute::libvirt::rx_queue_size/nova::compute::libvirt::tx_queue_size. However, there was no dedicated TripleO heat template parameter. With this release, the RX/TX queue size can be set on a role base like this:

parameter_defaults:
ComputeParameters:
NovaLibvirtRxQueueSize: 1024
NovaLibvirtTxQueueSize: 1024

The result is rx_queue_size/tx_queue_size is set using new parameters.

This update makes gnocchiclient available on the undercloud after switching to a containerized undercloud, allowing users to query for telemetry data.

This update makes gnocchiclient available on the undercloud after switching to a containerized undercloud, allowing users to query for telemetry data.

Blacklisting configuration updates against Ceph nodes no longer results in failed deployments.

Blacklisting configuration updates against Ceph nodes no longer results in failed deployments.

Deploying the overcloud with a Gnocchi file backend might fail due to access permissions to the /var/lib/gnocchi/ directory.

Workaround: Before you deploy the overcloud, set the permissions to the directory in the openstack/tripleo-heat-templates/docker/services/gnocchi-api.yaml file as follows:

        - path:
            list_join:
              - "/"
              - - {get_param: GnocchiFileBasePath}
                - "tmp"
          owner: gnocchi:gnocchi
          perm: '0600'
          recurse: true

Deploying the overcloud with a Gnocchi file backend might fail due to access permissions to the /var/lib/gnocchi/ directory.

Workaround: Before you deploy the overcloud, set the permissions to the directory in the openstack/tripleo-heat-templates/docker/services/gnocchi-api.yaml file as follows:

        - path:
            list_join:
              - "/"
              - - {get_param: GnocchiFileBasePath}
                - "tmp"
          owner: gnocchi:gnocchi
          perm: '0600'
          recurse: true

The OpenStack Platform director was not configuring authentication data required for the Block Storage service (cinder) to access privileged portions of the nova API. Because of this, operations on volumes that use nova's privileged API (e.g., migrating an in-use volume) would fail. The director now configures cinder with nova's authentication data. As a result, operations on volumes that require privileges work.

The OpenStack Platform director was not configuring authentication data required for the Block Storage service (cinder) to access privileged portions of the nova API. Because of this, operations on volumes that use nova's privileged API (e.g., migrating an in-use volume) would fail. The director now configures cinder with nova's authentication data. As a result, operations on volumes that require privileges work.

The neutron_driver is null in the containers-prepare-parameter.yaml file.
As a result, an OSP14 + ODL minor update will fail if following the general OSP update guide.

Workaround:
Before updating the overcloud, change neutron_driver to 'odl' in containers-prepare-parameter.yaml (see https://bugzilla.redhat.com/show_bug.cgi?id=1660454 ).

With this workaround, the OSP14 + ODL minor update should pass.

The neutron_driver is null in the containers-prepare-parameter.yaml file.
As a result, an OSP14 + ODL minor update will fail if following the general OSP update guide.

Workaround:
Before updating the overcloud, change neutron_driver to 'odl' in containers-prepare-parameter.yaml (see https://bugzilla.redhat.com/show_bug.cgi?id=1660454 ).

With this workaround, the OSP14 + ODL minor update should pass.

This update adds hostname and network name to the output of the 'openstack port list' command.
The additional information makes it easier to associate Neutron port and IP addresses with a particular host.

This update adds hostname and network name to the output of the 'openstack port list' command.
The additional information makes it easier to associate Neutron port and IP addresses with a particular host.

OSP-Director now supports setting specific IP addresses on the Control Plane (provisioning) network, similar to the way these are set for other networks. To set the IP addresses used during provisioning, set the IPs under the "ctlplane" network, one IP address per line. These will be assigned to the nodes in order (Compute-0, Compute-1, etc.)

For example::

parameter_defaults:
ControllerIPs:
ctlplane:
- 192.168.24.251
ComputeIPs:
ctlplane:
- 192.168.24.252
- 192.168.24.253

See the file in /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml for an example of usage.

Prior to this update, OSP-Director allowed the operator to choose the IP addresses used by each overcloud node on each network, but the provisioning IP addresses were random. With this update, OSP-Director supports selecting specific IP addresses for each role on every network.

OSP-Director now supports setting specific IP addresses on the Control Plane (provisioning) network, similar to the way these are set for other networks. To set the IP addresses used during provisioning, set the IPs under the "ctlplane" network, one IP address per line. These will be assigned to the nodes in order (Compute-0, Compute-1, etc.)

For example::

parameter_defaults:
ControllerIPs:
ctlplane:
- 192.168.24.251
ComputeIPs:
ctlplane:
- 192.168.24.252
- 192.168.24.253

See the file in /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml for an example of usage.

Prior to this update, OSP-Director allowed the operator to choose the IP addresses used by each overcloud node on each network, but the provisioning IP addresses were random. With this update, OSP-Director supports selecting specific IP addresses for each role on every network.

With this update, TripleO assigns the default volume type 'tripleo' when creating cinder volumes. Prior to this update, the lack of a volume type caused errors during volume retype and migration operations.
You can change a cinder volume type by overriding the CinderDefaultVolumeType parameter.
NOTE: If a cinder default volume type was manually configured (i.e. outside of the Tripleo director), set the CinderDefaultVolumeType parameter to the manually configured value when updating the overcloud nodes. This ensures the name of the default volume type doesn't change to the 'tripleo' default value.

With this update, TripleO assigns the default volume type 'tripleo' when creating cinder volumes. Prior to this update, the lack of a volume type caused errors during volume retype and migration operations.
You can change a cinder volume type by overriding the CinderDefaultVolumeType parameter.
NOTE: If a cinder default volume type was manually configured (i.e. outside of the Tripleo director), set the CinderDefaultVolumeType parameter to the manually configured value when updating the overcloud nodes. This ensures the name of the default volume type doesn't change to the 'tripleo' default value.

With this change nova-metadata-api is served via httpd wsgi in the nova_metadata container.
Note that upstream will deprecate usage of eventlet for all the WSGI-run services, including nova-api and nova-metadata-api. See https://review.openstack.org/#/c/549510/ for more details.

With this change nova-metadata-api is served via httpd wsgi in the nova_metadata container.
Note that upstream will deprecate usage of eventlet for all the WSGI-run services, including nova-api and nova-metadata-api. See https://review.openstack.org/#/c/549510/ for more details.

You can now configure automatic restart of instances on a Compute node if the compute node reboots without first migrating the instances. Nova and the libvirt-guests agent can be configured to gracefully shut down the instances and start them when the Compute node reboots.

New parameters:
NovaResumeGuestsStateOnHostBoot (True/False)
NovaResumeGuestsShutdownTimeout (default 300s)

You can now configure automatic restart of instances on a Compute node if the compute node reboots without first migrating the instances. Nova and the libvirt-guests agent can be configured to gracefully shut down the instances and start them when the Compute node reboots.

New parameters:
NovaResumeGuestsStateOnHostBoot (True/False)
NovaResumeGuestsShutdownTimeout (default 300s)

Previously, the loopback device for Cinder iSCSI/LVM backend was not recreated after a system restart, which prevented the cinder-volume service from restarting. This fix adds a systemd service that recreates the loopback device and therefore persists the Cinder iSCSI/LVM backend after a restart.

Previously, the loopback device for Cinder iSCSI/LVM backend was not recreated after a system restart, which prevented the cinder-volume service from restarting. This fix adds a systemd service that recreates the loopback device and therefore persists the Cinder iSCSI/LVM backend after a restart.

A group with no buckets causes Open vSwitch to assert, which results in a daemon crash. With this update, the code allows groups with no buckets. Groups with or without buckets do not trigger the assert.

A group with no buckets causes Open vSwitch to assert, which results in a daemon crash. With this update, the code allows groups with no buckets. Groups with or without buckets do not trigger the assert.

Restarting the service causes internal ports moved to another networking namespace to be recreated. When this happens, the ports lose their networking configuration and are recreated in the wrong networking namespace. With this release, the code does not recreate the ports when the service is restarted, which allows the ports to keep their networking configuration.

Restarting the service causes internal ports moved to another networking namespace to be recreated. When this happens, the ports lose their networking configuration and are recreated in the wrong networking namespace. With this release, the code does not recreate the ports when the service is restarted, which allows the ports to keep their networking configuration.

In some OVS versions, updelay and downdelay bond settings are ignored, and the default settings are always used.

In some OVS versions, updelay and downdelay bond settings are ignored, and the default settings are always used.

With this release, 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 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 nova.conf for usage details.

With this release, 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 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 nova.conf for usage details.

With this update, logrotate's copytruncate is used by default for containerized services logs rotation. The default period to keep old logs remains unchanged (14 days).

With this update, logrotate's copytruncate is used by default for containerized services logs rotation. The default period to keep old logs remains unchanged (14 days).

Cause: When resolving hostnames, python-amqp requests both A and AAAA records.

Consequence: If an A record is successfully retrieved, a request for AAAA is still sent.  If the resolver is not able to resolve the AAAA record request, the entire operation must wait for the timeout on the AAAA request.  This causes name resolution to take longer than necessary, and may cause AMQP messaging operations to be slow or timeout entirely.

Fix: If an A record is successfully returned, do not request the AAAA record.  Simply use the successful A record.

Result: Name lookups resolve quickly.

Cause: When resolving hostnames, python-amqp requests both A and AAAA records.

Consequence: If an A record is successfully retrieved, a request for AAAA is still sent.  If the resolver is not able to resolve the AAAA record request, the entire operation must wait for the timeout on the AAAA request.  This causes name resolution to take longer than necessary, and may cause AMQP messaging operations to be slow or timeout entirely.

Fix: If an A record is successfully returned, do not request the AAAA record.  Simply use the successful A record.

Result: Name lookups resolve quickly.

Some versions of OpenStack TripleO Heat templates contained incorrect settings for the Neutron service_plugins parameter, which prevented Octavia from working with OVN. This release upgrades the OVN version to support Octavia with the following package: openstack-tripleo-heat-templates-9.0.1-0

Some versions of OpenStack TripleO Heat templates contained incorrect settings for the Neutron service_plugins parameter, which prevented Octavia from working with OVN. This release upgrades the OVN version to support Octavia with the following package: openstack-tripleo-heat-templates-9.0.1-0

Previously, threading events with eventlet created unnecessary system calls, which reduced performance of the REST API and resulted in timeout failures in Tempest. This fix improves the response time of the REST API calls, and reduces timeout failures in Tempest.

Previously, threading events with eventlet created unnecessary system calls, which reduced performance of the REST API and resulted in timeout failures in Tempest. This fix improves the response time of the REST API calls, and reduces timeout failures in Tempest.

This update corrects an issue that prevented the system from properly shutting down and waiting for containers to stop on reboot.
That issue could cause the containers to get killed before they stopped properly.
This update adds a new service which ensures that the system waits for the containers to fully stop before continuing during the reboot.

This update corrects an issue that prevented the system from properly shutting down and waiting for containers to stop on reboot.
That issue could cause the containers to get killed before they stopped properly.
This update adds a new service which ensures that the system waits for the containers to fully stop before continuing during the reboot.

Previously, API requests to the policies file for checking non-admin user access permissions caused the entire file to reload and reparse. This resulted in slower processing time and degraded performance.

This bug fix adds caching of the policies file so that queries to the file do not reload the entire file. Now, only changes to the file result in reloading and reparsing the file.

Previously, API requests to the policies file for checking non-admin user access permissions caused the entire file to reload and reparse. This resulted in slower processing time and degraded performance.

This bug fix adds caching of the policies file so that queries to the file do not reload the entire file. Now, only changes to the file result in reloading and reparsing the file.

Rebase package(s) to version:
python-tempestconf-2.0.0

In this rebase, the python-tempestconf tool went through a major refactoring to ease the process of generating tempest.conf.
This rebase also fixes many outstanding bugs and brings support for new services.
Moving to the new release provides many benefits to tempest users.
For details, see the OpenStack release notes:
https://docs.openstack.org/releasenotes/python-tempestconf/unreleased.html#relnotes-2-0-0

Rebase package(s) to version:
python-tempestconf-2.0.0

In this rebase, the python-tempestconf tool went through a major refactoring to ease the process of generating tempest.conf.
This rebase also fixes many outstanding bugs and brings support for new services.
Moving to the new release provides many benefits to tempest users.
For details, see the OpenStack release notes:
https://docs.openstack.org/releasenotes/python-tempestconf/unreleased.html#relnotes-2-0-0

OpenStack director now uses Ansible for software configuration of the overcloud nodes. Ansible provides a more familiar and debuggable operator experience during overcloud deployment. Ansible is used to replace the communication and transport of the software configuration deployment data between heat and the heat agent (os-collect-config) on the overcloud nodes.

Instead of os-collect-config running on each overcloud node and polling for deployment data from heat, the Ansible control node applies the configuration by running an ansible-playbook with an Ansible inventory file and a set of playbooks and tasks. The Ansible control node (the node running ansible-playbook) is the undercloud by default.

OpenStack director now uses Ansible for software configuration of the overcloud nodes. Ansible provides a more familiar and debuggable operator experience during overcloud deployment. Ansible is used to replace the communication and transport of the software configuration deployment data between heat and the heat agent (os-collect-config) on the overcloud nodes.

Instead of os-collect-config running on each overcloud node and polling for deployment data from heat, the Ansible control node applies the configuration by running an ansible-playbook with an Ansible inventory file and a set of playbooks and tasks. The Ansible control node (the node running ansible-playbook) is the undercloud by default.

The default value of --http-boot changed from /httpboot to
/var/lib/ironic/httpboot as containerized Ironic services
expect.

The default value of --http-boot changed from /httpboot to
/var/lib/ironic/httpboot as containerized Ironic services
expect.

Previously, sending an IPMI bootdev command caused some hardware to unexpectedly change the boot device order. This prevented some nodes from booting from the correct NIC or prevented PXE from booting from any location.

This release adds a noop management interface for the IPMI driver. This interface handles boot commands and prevents bootdev from being used. To prepare for the noop interface, you must pre-configure nodes to attempt PXE boot mode from the correct NIC, and then fallback to the local hard drive.

Previously, sending an IPMI bootdev command caused some hardware to unexpectedly change the boot device order. This prevented some nodes from booting from the correct NIC or prevented PXE from booting from any location.

This release adds a noop management interface for the IPMI driver. This interface handles boot commands and prevents bootdev from being used. To prepare for the noop interface, you must pre-configure nodes to attempt PXE boot mode from the correct NIC, and then fallback to the local hard drive.

This update fixes a debug message interpolation bug that caused server crashes when responses were rendered with debug mode activated.

This update fixes a debug message interpolation bug that caused server crashes when responses were rendered with debug mode activated.

During package installation, a bug in the RPM spec for the virtualbmc package caused special users or groups that run the virtualbmc service to not be created. This update fixes the RPC spec to ensure successful user management operations. The virtualbmc service can be successfully started upon package installation.

During package installation, a bug in the RPM spec for the virtualbmc package caused special users or groups that run the virtualbmc service to not be created. This update fixes the RPC spec to ensure successful user management operations. The virtualbmc service can be successfully started upon package installation.

VirtualBMC (VBMC) is no longer supported, and should not be used in production environments. For testing purposes, you can install VBMC directly with pip.

VirtualBMC (VBMC) is no longer supported, and should not be used in production environments. For testing purposes, you can install VBMC directly with pip.

Director and openshift-ansible have different expectations regarding image tags. For example, when importing the remote container images locally, director converts the generic tag into one that uniquely identifies the image based on the version and release labels from the image metadata. Openshift-ansible, however, relies on a unique openshift_image_tag variable for all the openshift images tags making it impossible to specify tags of images individually. Deployment of OCP via director fails when the floating v3.11 tag in the remote container image registry points to images with non-consistent release or version labels in their metadata.

From the undercloud, import the odd images prior to deploying OpenShift and set the tag to be consistent across all openshift images:

  skopeo --tls-verify=false copy docker://registry.access.redhat.com/openshift3/prometheus:v3.11.51-1 docker://192.168.24.1:8787/openshift3/prometheus:v3.11.51-2

Deployment of OpenShift from director completes without missing image.

Director and openshift-ansible have different expectations regarding image tags. For example, when importing the remote container images locally, director converts the generic tag into one that uniquely identifies the image based on the version and release labels from the image metadata. Openshift-ansible, however, relies on a unique openshift_image_tag variable for all the openshift images tags making it impossible to specify tags of images individually. Deployment of OCP via director fails when the floating v3.11 tag in the remote container image registry points to images with non-consistent release or version labels in their metadata.

From the undercloud, import the odd images prior to deploying OpenShift and set the tag to be consistent across all openshift images:

  skopeo --tls-verify=false copy docker://registry.access.redhat.com/openshift3/prometheus:v3.11.51-1 docker://192.168.24.1:8787/openshift3/prometheus:v3.11.51-2

Deployment of OpenShift from director completes without missing image.

Prior to this update, controllers with a large amount of RAM could experience soft lockups. This would occur due to memory pressure as the dentry cache on controller nodes would grow continually. Now, prior to doing a curl statement in the container health check, the NSS_SDB_USE_CACHE environment variable is set to 'no', which prevents cache growth.

Prior to this update, controllers with a large amount of RAM could experience soft lockups. This would occur due to memory pressure as the dentry cache on controller nodes would grow continually. Now, prior to doing a curl statement in the container health check, the NSS_SDB_USE_CACHE environment variable is set to 'no', which prevents cache growth.

Director does not support triggering Red Hat Enterprise Linux OS and OpenShift Container Platform updates on director deployed OpenShift environments. Director deployed OpenShift environments cannot be minor updated.

Director does not support triggering Red Hat Enterprise Linux OS and OpenShift Container Platform updates on director deployed OpenShift environments. Director deployed OpenShift environments cannot be minor updated.

Scaling out with an additional OpenShift master node of a director deployed OpenShift environment fails with a message similar to: "The field 'vars' has an invalid value, which includes an undefined variable. The error was: 'openshift_master_etcd_urls' is undefined…”

Scaling out with an additional OpenShift master node of a director deployed OpenShift environment fails with a message similar to: "The field 'vars' has an invalid value, which includes an undefined variable. The error was: 'openshift_master_etcd_urls' is undefined…”

This  update fixes an issue that prevented users from successfullly re-running a failed OSP13-to-OSP14 upgrade of OpenStack Platform director.
Some upgrade failures resulted in a state where services were not yet deployed with docker, which prevented a successful re-run of the upgrade.

Now a check is performed to verify that the services are deployed under docker control, enabling a successful re-run.

This  update fixes an issue that prevented users from successfullly re-running a failed OSP13-to-OSP14 upgrade of OpenStack Platform director.
Some upgrade failures resulted in a state where services were not yet deployed with docker, which prevented a successful re-run of the upgrade.

Now a check is performed to verify that the services are deployed under docker control, enabling a successful re-run.

This update adds an 'any_errors_fatal' setting to stop an upgrade after an upgrade task failure on any overcloud node.

Prior to this update, after an upgrade failure on one overcloud node, the upgrade would continue on other overcloud nodes.

Now, if an upgrade task fails on any overcloud node, the upgrade is stopped and does not progress onto next tasks on other overcloud nodes.

This update adds an 'any_errors_fatal' setting to stop an upgrade after an upgrade task failure on any overcloud node.

Prior to this update, after an upgrade failure on one overcloud node, the upgrade would continue on other overcloud nodes.

Now, if an upgrade task fails on any overcloud node, the upgrade is stopped and does not progress onto next tasks on other overcloud nodes.

Prior to this update, there was no way to completely disable the Panko service using the Tripleo heat templates.

This is resolved with the newly added parameter, CeilometerEnablePanko. To disable the Panko service, set this parameter to False.

Prior to this update, there was no way to completely disable the Panko service using the Tripleo heat templates.

This is resolved with the newly added parameter, CeilometerEnablePanko. To disable the Panko service, set this parameter to False.

Glance image conversion is not enabled by default on a new install of Red Hat OpenStack Platform 14. To use this feature, edit the glance-image-import.conf file.
In the image_import_opts section, insert the following line:
image_import_plugins = ['image_conversion']

Glance image conversion is not enabled by default on a new install of Red Hat OpenStack Platform 14. To use this feature, edit the glance-image-import.conf file.
In the image_import_opts section, insert the following line:
image_import_plugins = ['image_conversion']

This feature adds the capability to configure the Cinder Dell EMC StorageCenter driver to use a multipath for volume-to-image and image-to-volume transfers. The feature includes a new parameter CinderDellScMultipathXfer with a default value of True. Enabling multipath transfers can reduce the total time of data transfers between volumes and images.

This feature adds the capability to configure the Cinder Dell EMC StorageCenter driver to use a multipath for volume-to-image and image-to-volume transfers. The feature includes a new parameter CinderDellScMultipathXfer with a default value of True. Enabling multipath transfers can reduce the total time of data transfers between volumes and images.

Previously, the glance-api container image was missing a python library used for managing fibre channel connections. As a result, attempts to create an image on storage would fail when using this medium.

This update provides the python library. The glance-api container now successfully accesses fibre channel storage.

Previously, the glance-api container image was missing a python library used for managing fibre channel connections. As a result, attempts to create an image on storage would fail when using this medium.

This update provides the python library. The glance-api container now successfully accesses fibre channel storage.