4.2. RHEA-2018:2670 — Red Hat OpenStack Platform 10 Enhancement Update

instack-undercloud

BZ#1582662

Previously, Undercloud upgrade failed due to dependency issues.

With this fix, the upgrade procedure automatically removes the mariadb-devel and neutron-vpnaas packages from the Undercloud before running the FFWD. As a result, the Undercloud upgrade succeeds.

openstack-tripleo-heat-templates

BZ#1584582

	NFV deployments require additional scripts to be executed as NodeUserData and NodeExtraConfigPost during the deployment. This configures the kernel args and configure tuned with a reboot before starting the puppet execution. Previously, these files were part of the documentation, but with this release, the files are in the tripleo-heat-templates repository. If the deployment has additional user changes, copy this file, add the additional changes, and use the new file for the deployment.

	For OVS-DPDK deployments:
	resource_registry:
	  OS::TripleO::Compute::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_nfv_ovsdpdk.yaml
	  OS::TripleO::NodeExtraConfigPost: /usr/share/openstack-tripleo-heat-templates/extraconfig/post_deploy/post_deploy_nfv.yaml


	For SR-IOV deployments:
	resource_registry:
	  OS::TripleO::Compute::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_nfv_sriov.yaml
	  OS::TripleO::NodeExtraConfigPost: /usr/share/openstack-tripleo-heat-templates/extraconfig/post_deploy/post_deploy_nfv.yaml


	NOTE: These files are based only on the Compute role. If you create composable roles with NFV services, you must modify these files and registry mapping according to your requirements.

BZ#1597997

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

As a result, live-migration failed with the error:

Live Migration failure: internal error: Unable to find an unused port in range 'migration' (49152-49215).

With this update, the new libvirtd live-migration range of 61152-61215 is not in the ephemeral range and the related failures no longer occur.

This completes the port change work started in BZ1573796.

BZ#1618797

Previously, OpenStack special handling did not upgrade all dependent packages before installing openvswitch during an upgrade, resulting in openvswitch package upgrade failure.

With this update, OpenStack special handling upgrades all dependent packages and the openvswitch upgrade is successful.

BZ#1601708

With this update, the hugetlbfs gid value correlates to the kolla fixed gid value to allow easy migration to Red Hat OpenStack Platform 13, where libvirt runs in a kolla container.

BZ#1599368

With this update, parallelization of the selinux permission change enables faster upgrade of Ceph OSD.

BZ#1599370

Previously, when upgrading from OpenStack 9 to OpenStack 10, Ceph clusters had a default status of 'health_warn'.

With this update, Ceph clusters have a status of 'OK' after upgrading to OpenStack 10.

puppet-nova

BZ#1571756

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

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

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

BZ#1579699

With this enhancement, the Nova 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.

In this update, the restriction of using only the PCID flag is extended to expose multiple CPU feature flags.

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

puppet-tripleo

BZ#1605973

Previously, the xinetd service that provides the 'clustercheck' status for the Galera database was bound to all interfaces. This means that in a Controller node where a network interface was exposed to an untrusted network, an attacker could flood the xinetd service with requests and render it unavailable due to the relatively low request limit.

With this update, the clustercheck xinetd service is now bound to the network interface for internal Galera communication, and the xinetd service is no longer exposed to all network interfaces.

BZ#1520799

Previously, the cookie set in the horizon stanza for haproxy was incorrect and connections to horizon may be load balanced to the wrong server.

With this update, the cookie now points to the correct server.

BZ#1589361

Previously, it was not possible to customize the haproxy [defaults] section in the haproxy.cnf file. It was necessary to modify this section manually.

With this update, you can pass in a new hierakey and override the defaults. For example, to set the default retries to 7, you can pass in the following hierakey:

parameter_defaults:
ExtraConfig:
tripleo::haproxy::haproxy_defaults_override:
  retries: 7

BZ#1595315

During a version upgrade, the Block Storage Service (cinder) database synchronization is now executed only on the bootstrap node. This prevents database synchronization and upgrade failures that occurred when database synchronization was executed on all Controller nodes.

BZ#1598428

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

With this update, Puppet now sets the file ACLs mask for the CephX keyrings so that it can grant read permissions to specific users. This allows a non-containerized OpenStack service to connect to the Ceph cluster.

BZ#1436495

Since the release of the new HA architecture in Red Hat OpenStack Platform version 10, the majority of services are now managed by systemd. All OpenStack services are configured to restart automatically if they fail unexpectedly.

However, non-OpenStack services have a default configuration which does not enable automatic restart on failure. For example, if memcached, apache, or mongodb fail, you must restart these services manually. This may lead to service disruption if failure happens on all nodes.

With this update, the systemd unit files of these services include the option to restart automatically if the services fail.

BZ#1567368

Previously, the CinderNetappNfsMountOptions TripleO Heat parameter was inadvertently ignored, and was not used to configure the corresponding setting in the cinder Netapp backend. As a result, it was not possible to configure the Netapp NFS mount options with the TripleO Heat parameter.

With this update, the code responsible for handling the cinder Netapp configuration no longer ignores the CinderNetappNfsMountOptions parameter and the CinderNetappNfsMountOptions parameter correctly configures the cinder Netapp NFS mount options.

BZ#1598562

Previously, all overcloud nodes were deployed with the same iSCSI initiator name (IQN). This is a consequence of using a common overcloud image. Later in the deployment, the IQN is reset on Compute nodes. However, the IQN is not reset on Controllers, which also need to support iSCSI
connections. As a result, all overcloud Controller nodes have the same IQN, which causes
iSCSI connections to fail.

With this update, the IQN is now reset on both Controller and Compute nodes and Controllers can create reliable iSCSI connections because all of the Controllers have a unique IQN.

NOTE: The IQN on an overcloud node should be reset once, and only once. If a user has already manually reset the IQN on an overcloud node, then care must be taken to ensure that TripleO does not reset the IQN a second time.

TripleO uses a sentinel file (/etc/iscsi/.initiator_reset) to determine whether it should reset the node IQN. To prevent TripleO from resetting the IQN on a node, run the following command on that node:

sudo touch /etc/iscsi/.initiator_reset

python-os-brick

BZ#1572574

Previously, the OS-Brick FC code scanned all present HBAs, which could unintentionally add unwanted devices.

With this update, OS-Brick FC code scans HBAs that match the following criteria:

- HBAs in an initiator map, if present.
- HBAs that are connected in the single WWNN for all ports case.
- HBAs with wildcards.