Release Notes

[reponame]

#subscription-manager repos --enable=[reponame]
#subscription-manager repos --disable=[reponame]
parameter_defaults:
  ComputeOvsDpdkParameters:
    NovaComputeCpuSharedSet: "0-1"
HostCpusList: "0-1"
hw:emulator_threads_policy=share
workflow_parameters:  tripleo.derive_params.v1.derive_parameters:
    num_phy_cores_per_numa_node_for_pmd: 2
    huge_page_allocation_percentage: 90
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.
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'.
Heat templates now include the `CephClusterName` parameter. This parameter enables you to customize the Ceph cluster name, which you might need to do if you use an external Ceph cluster or a Ceph RBDMirror.
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
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.
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.
Instance resources have three new attributes: launched_at, deleted_at, created_at to track the exact time that Nova creates/launches/deletes instances.
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 Sahara now supports Cloudera Distribution Hadoop (CDH) plugin 5.13.
This update adds support of s3-compatible object stores for OpenStack Sahara.
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.
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.
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
Red Hat OpenStack Platform 14 is now supported on IBM POWER9 CPUs. This support is provided with the `rhosp-director-images-ppc64lep9` and `rhosp-director-images-ipa-ppc64lep9` packages.
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 feature enables forwarding tenant traffic based on DSCP marking from tenants encapsulated in the VXLAN IP header. This feature is a technology preview for OSP14.
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)
The default value of `--http-boot` changed from `/httpboot` to
`/var/lib/ironic/httpboot` as containerized Ironic services
expect.
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).
OpenStack Rally, previously included as a technical preview, is removed from this release.
When you use the web-download feature, the staging area - defined in the configuration using the `node_staging_uri` option - is not cleaned up properly. Ensure that `file` is part of the `stores` configuration option in the `glance_store` section of the glance-api.conf file.
When you use the image conversion feature, ensure that `file` is part of the `stores` configuration option in the `glance_store` section of the glance-api.conf file.
For glance image conversion, the glance-direct method is not enabled by default. To enable this feature, set `enabled_import_methods` to `[glance-direct,web-download]` or `[glance-direct]` in the DEFAULT section of glance-api.conf.
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']
OpenDaylight does not support IPv6 for tenant or provider networks. Therefore, use only IPv4 networks. You may experience issues related to floating IPs if IPv6 networks are used along with IPv4 networks.
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.
When Octavia is configured to use a small Nova flavor, Amphorae (Nova instances) are created successfully but load balancers can get stuck in PENDING state for about 25 minutes. Instead, the load balancer should go to error state and the Amphorae should be deleted.

As a workaround for small Nova flavors, tune Octavia configurations "connection_max_retries", "connection_retry_interval", "build_active_retries" and "build_retry_interval" in section [haproxy_amphora] to a more reasonable production values. This will cause load balancers will transition from PENDING to ERROR state faster with a small Nova flavor.
Workflow triggers for generating Openstack rc files are hardcoded in python-tripleoclient.
As a result, OpenStack-specific workflows are triggered after director deploys OpenShift. Users can see OpenStack-specific URLs in stdout and OpenStack rc files created.
There is currently a known issue with fernet token rotation where the keys are not automatically deployed onto the overcloud. The workflow task `tripleo.fernet_keys.v1.rotate_fernet_keys ` generates the keys but they are not successfully pushed to the overcloud. This issue is expected to be addressed in a future release. If you plan to perform rotation before this update, you can choose to follow one of these workarounds:
* Start os-collect-config on the overcloud nodes before running the rotation. You can then stop it afterwards if you do not need it for anything else.
* Enable os-collect-config on all overcloud nodes. You can choose to disable it once the update with the fix is released.
NOTE: If you do not need to rotate keys before the update comes out, then you do not need to do anything.
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
On a director-deployed OpenShift environment, the GlusterFS playbooks auto-generate a new heketi secret key for each run.
As a result of this, operations such as scale out or configuration changes on CNS deployments fail.

As a workaround, complete the following steps:
1. Post-deployment, retrieve the heketi secret key. Use this command on one of the master nodes:
sudo oc get secret heketi-storage-admin-secret --namespace glusterfs -o json | jq -r .data.key | base64 -d
2. In an environment file, set the following parameters to that value:
  openshift_storage_glusterfs_heketi_admin_key
  openshift_storage_glusterfs_registry_heketi_admin_key

As a result of this workaround, operations such as scale out or configuration changes on CNS deployments work as long as the parameters were manually extracted.
When you restart all three controller nodes, it might not be possible to launch tenant instances in the overcloud. A "DuplicateMessageError" message  is logged in the overcloud logs.
As a workaround,  on one of the overcloud controllers, run this command:
pcs resource restart rabbitmq-bundle
For proxying requests to the routers on Infra nodes, director sets up port 443 on the HAProxy instance running on master nodes. Port 443 cannot be used on OpenShift master nodes for binding the OpenShift API. OpenShift API cannot be configured on port 443 on a director deployed OpenShift environment.
The overcloud-full image provided by director causes an RPM conflict with the python-setuptools provided by the OpenShift repos. Any post-deployment yum update on the OpenShift nodes fails with a broken dependency issue.

To fix this, run the following on the undercloud:
source ~/stackrc
tripleo-ansible-inventory --stack openshift --static-yaml-inventory
/home/stack/openshift_inventory.yaml
export ANSIBLE_HOST_KEY_CHECKING=False
ansible -i openshift_inventory.yaml -m shell -b -a 'rpm -e --nodeps python-setuptools-0.9.8-7.el7.noarch; yum -y install python-setuptools' overcloud

This update replaces the python-setuptools provided by the overcloud-full image with the version provided by the OpenShift repos. Any subsequent yum updates are successful.
In some OVS versions, `updelay` and `downdelay` bond settings are ignored, and the default settings are always used.
Nova-compute ironic driver tries to update BM node while the node is being cleaned up. The cleaning takes approximately five minutes but nova-compute attempts to update the node for approximately two minutes. After timeout, nova-compute stops and puts nova instance into ERROR state.

As a workaround, set the following configuration option for nova-compute service:
[ironic]
api_max_retries = 180

As a result, nova-compute continues to attempt to update BM node longer and eventually succeeds.
The `neutron_driver` parameter has the value `null` in the containers-prepare-parameter.yaml file. This might cause minor updates to the overcloud in OpenDaylight deployments.

Workaround: Before you update the overcloud, set the value of the `neutron_driver` parameter to `odl`.
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 Infra node on a director deployed OpenShift environment with CNS enabled fails with a message similar to the following: “fatal: [openshift-master-2]: FAILED! => {"changed": false, "msg": "Error mounting /tmp/openshift-glusterfs-registry-c8qImT: Mount failed.”
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 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.
After config-download has generated the playbooks for the Overcloud, if you execute ansible-playbook with --check parameter, it does not work. Expect an error about undefined stdout for ftype. This will be fixed in the next version.
Due to a known Ansible issue (https://github.com/ansible/ansible/issues/24449) changes to /etc/ssh/ssh_known_hosts are not propagated to existing nova_compute and nova_libvirt containers within an environment after adding compute hosts.

As a result, live migration, cold migration and instance resize operations using the newly introduced compute hosts will fail as a result as the original hosts will not have the required public SSH keys.

Workaround:
Restarting all nova_compute and nova_libvirt containers will ensure the updates to /etc/ssh/ssh_known_hosts are correctly written.

Detailed steps can be found in the following KCS article:

[OSP14] After successful scale out, live/cold migration and resize fails to the new added compute with 'Host key verification failed'
https://access.redhat.com/solutions/3792021
A recent change made memory allocation for instances with NUMA topologies pagesize aware. With this change, memory for instances with NUMA topologies can no longer be oversubscribed.

Memory oversubscription is currently disabled for all instances with a NUMA topology, whereas previously only instances with hugepages were not allowed to use oversubscription. This affects instances with an explicit NUMA topology and those with an implicit topology. An instance can have an implicit NUMA topology due to the use of hugepages or CPU pinning.

If possible, avoid the use of explicit NUMA topologies. If CPU pinning is required, resulting in an implicit NUMA topology, there is no workaround.
OpenDaylight was first made available in OSP 13 and is being deprecated in OSP 14.

Our combined OpenDaylight in OpenStack solution will no longer accept new feature enhancements and we would like to inform those who were looking for an OpenDaylight integrated solution from Red Hat to seek alternatives.

OpenDaylight will continue to be supported and receive bug fixes for the duration of the OSP 14 deprecation cycle, with support planned to be completely dropped by the end of the OSP 13 lifecycle (June 27, 2021).
This enhancement adds the boolean parameter `NovaLibvirtVolumeUseMultipath`, which provides a value for the multipath configuration parameter `libvirt/volume_use_multipath` in the `nova.conf` file for Compute nodes. You can set this parameter for each Compute role. Default value is `False`.
This enhancement sets the number of RPC workers to `1` by default in OVN tripleo deployments. The goal of this setting is to reduce the number of workers to save memory resources and the number of connections to OVSDB, in cases where the Neutron DHCP agent is not deployed alongside OVN services.
This enhancement adds the networking-ansible heat parameter `IronicDefaultNetworkInterface`, which determines the value of the `default_network_interface` parameter in the `ironic.conf` configuration file. This value is set to the  `neutron` interface by default, which enables virtual networking through Neutron on bare metal nodes.

Note: The switches attached to the bare metal nodes must be programmable by the networking service if the `default_network_interface` is set to `neutron`.
There is currently a known issue where director can hang while deploying OCP. This occurs because the fix described in https://bugzilla.redhat.com/show_bug.cgi?id=1671861 is not a part of the `overcloud-full` image for the Red Hat OpenStack Platform 14 z1 release.
As a workaround, prior to deploying the overcloud, follow the steps below to update the docker package in the `overcloud-full` image. For more information on this procedure, see https://access.redhat.com/articles/1556833.
After completing these steps, you can expect the director to successfully deploy OCP:

$ sudo yum install -y libguestfs-tools
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --install docker
$ source stackrc
$ openstack overcloud image upload --update-existing
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, when using TLS Everywhere, your controller node was required to access IdM through the `ctlplane` network. As a result, if traffic was routed through a different network, then the overcloud deployment process would fail due to `getcert` errors. To address this, IdM enrolment has been moved into a composable service that runs within `host_prep_tasks`; this runs at the start of the deployment phase. Note that the script will simply exit if the instance has already been enrolled in IdM.
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…”
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.
A recent change made memory allocation for instances with NUMA topologies pagesize aware. With this change, memory for instances with NUMA topologies can no longer be oversubscribed.

Memory oversubscription is currently disabled for all instances with a NUMA topology, whereas previously only instances with hugepages were not allowed to use oversubscription. This affects instances with an explicit NUMA topology and those with an implicit topology. An instance can have an implicit NUMA topology due to the use of hugepages or CPU pinning.

If possible, avoid the use of explicit NUMA topologies. If CPU pinning is required, resulting in an implicit NUMA topology, there is no workaround.
There is currently a known issue where director can hang while deploying OCP. This occurs because the fix described in https://bugzilla.redhat.com/show_bug.cgi?id=1671861 is not a part of the `overcloud-full` image for the Red Hat OpenStack Platform 14 z1 release.
As a workaround, prior to deploying the overcloud, follow the steps below to update the docker package in the `overcloud-full` image. For more information on this procedure, see https://access.redhat.com/articles/1556833.
After completing these steps, you can expect the director to successfully deploy OCP:

$ sudo yum install -y libguestfs-tools
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --install docker
$ source stackrc
$ openstack overcloud image upload --update-existing
As of this release the director graphical user interface is deprecated. Bug fixes and support will be provided through the end of the OSP 13 lifecycle but no new feature enhancements will be made.
Red Hat OpenStack Platform director now has the ability to control Block Storage service (Cinder) snapshots on NFS back ends. A new director parameter, CinderNfsSnapshotSupport, has a default value of True.
Prior to this release, the communication between hapoxy and the Shared File Systems service (Manila) API was not secured when deployed with TLS everywhere. Support has been added for the Manila API to configured with SSL certificates, allowing TLS on the internal API network. This feature is now automatically configured when TLS everywhere is enabled.
The API for the OpenStack Shared File Systems service (Manila) now runs behind httpd. The Apache error and access logs for this service are available in `/var/log/containers/httpd/manila-api` on all nodes that run the Manila API container. The logs for the main API remain in `/var/log/containers/manila`.
Previously, when the `PING` type health monitor was configured, HAProxy would silently use TCP connect instead. This is because Red Hat OpenStack Platform uses an older version of HAProxy that does not support external monitors. The setting `allow_ping_health_monitors` is now set to `False` by default.
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.
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.
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.
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 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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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, 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
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.
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.
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 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.
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 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)
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.
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.
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).
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
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.
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
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.
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.
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.
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.
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…”
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.
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']
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.

Repository Name	Repository Label
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 14 for RHEL 7 (RPMs)	`rhel-7-server-openstack-14-rpms`
Red Hat Enterprise Linux 7 Server - Extras (RPMs)	`rhel-7-server-extras-rpms`

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

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

Repository Name	Repository Label
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 14

OpenStack Documentation Team

Chapter 1. Introduction

1.1. About this Release

1.2. Requirements

1.3. Deployment Limits

1.4. Database Size Management

1.5. Certified Drivers and Plug-ins

1.6. Certified Guest Operating Systems

1.7. Bare Metal Provisioning Operating Systems

1.8. Hypervisor Support

1.9. Content Delivery Network (CDN) Repositories

1.10. Product Support

Chapter 2. Top New Features

2.1. Red Hat OpenStack Platform Director

2.2. Bare Metal Service

2.3. Ceph Storage

2.4. Compute

2.5. Metrics and Monitoring

2.6. Network Functions Virtualization

2.7. OpenStack Networking

2.8. Storage

2.9. Technology Previews

2.9.1. New Technology Previews

Chapter 3. Release Information

3.1. Red Hat OpenStack Platform 14 GA

3.1.1. Enhancements

3.1.2. Technology Preview

3.1.3. Release Notes

3.1.4. Known Issues

3.1.5. Deprecated Functionality

3.2. Red Hat OpenStack Platform 14 Maintenance Release - March 13, 2019

3.2.1. Enhancements

3.2.2. Known Issues

3.3. Red Hat OpenStack Platform 14 Maintenance Release - April 30, 2019

3.3.1. Enhancements

3.3.2. Known Issues

3.3.3. Deprecated Functionality

3.4. Red Hat OpenStack Platform 14 Maintenance Release - July 1, 2019

3.4.1. Enhancements

3.4.2. Release Notes

3.4.3. Known Issues

3.5. Red Hat OpenStack Platform 14 Maintenance Release - November 6, 2019

Chapter 4. Technical Notes

4.1. RHEA-2019:0045 — openstack director bug fix advisory

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links