Release Notes

Compatibility Mode

#subscription-manager repos --enable=[reponame]
#subscription-manager repos --disable=[reponame]
{"devices": [{
  "type": "nic",
  "bus": "pci",
  "address": "0000:00:02.0",
  "mac": "01:22:22:42:22:21",
  "tags": ["nfvfunc1"]
  "vlans":[300,1000]
  }]
}

This update adds a new user details page to the dashboard.  As a result you can click on the user ID in the Action Log to be taken directly to the user details page.
This update adds a new user details page to the dashboard.  As a result you can click on the user ID in the Action Log to be taken directly to the user details page.
The Time Series Database as a Service (gnocchi) and Aodh API endpoints now expose a `/healthcheck` HTTP endpoint on the REST API. Requesting this endpoint allows you to check the status of the service, and does not require authentication.
Automatic fencing setup can be used in director for easier High Availability deployments and upgrades. To benefit from the new feature, use the 'overcloud generate fencing' command.
The administrator needs to record the user credentials during the volume transfer operation and doing so by hand is inconvenient. 

With this update, a new button to download the credentials has been added to the volume transfer screen for saving the information easily. This allows the administrators to download and save a CSV file locally on their computer with the click of a button.
This enhancement adds the ability to automatically reschedule load balancers from LBaaS agents that the server detects as dead. Previously, load balancers could be scheduled and realized across multiple LBaaS agents, however if a hypervisor died, the load balancers scheduled
to that node would cease operation. With this update, these load balancers will be automatically rescheduled to a different agent. This feature is disabled by default and managed using `allow_automatic_lbaas_agent_failover`.
This enahncement implements the 'ProcessMonitor' class in the 'HaproxyNSDriver' class (v2), This class utilizes the 'external_process' module to monitor and respawn HAProxy processes if and when needed. The LBaaS agent (v2) loads 'external_process' related options and take a configured action when HAProxy dies unexpectedly.
This update adds support for the version 5.1.0 MapR plugin.
A disk can be in a variety of states which may cause director to fail when attempting to make the disk a Ceph OSD. In previous releases, a user could run a first-boot script to erase the disk and set a GPT label required by Ceph. With this release, a new default setting in Ironic will erase the disks when a node is set to available and a change in puppet-ceph will give the disk a GPT label if there is no GPT label on the disk.
This update provides enhancements to the CephFS Native Driver in conjunction with the core OpenStack File Share Service (manila) infrastructure. The CephFS Native driver now supports read-only shares and includes improvements to access rule update recovery mode.
To avoid memory bloat issues in the nova-api workers, pagination logic has been added to the simple-tenant-usage API extension.
With this enhancement, you can now enable the creation of non-public shares in the Dashboard.
You can configure Dashboard to hide the checkbox that enables users to mark shares as public during the creation process. The default option will be to create shares as private without the box checked.
With this enhancement, `glance-manage db purge` can now remove rows that are less than one day old. This was added because operators may need to run this operation on a regular basis.
As a result, the value of the `age_in_days` option can be set to `0`.
This release features the necessary puppet modules for deploying CephFS. This allows you to deploy the OpenStack Shared File System service (openstack-manila) with a CephFS back-end through the director.
This enhancement makes Time Series Database as a Service (gnocchi) available in the undercloud. Gnocchi provides metrics backend for Telemetry in OpenStack, and is enabled by default with the `enable_telemetry` flag set to `true`. All telemetry services can be disabled by setting `enable_telemetry=false` in `undercloud.conf`.
This release adds pagination support to avoid resource-consuming usage requests on systems with a large number of instances. The v2.40 microversion of the nova API simple-tenant-usage endpoints use new optional query parameters 'limit' and 'marker' for pagination. The 'marker' option sets the starting point and the 'limit' option sets the number of records to be displayed after the starting point. If 'limit' is not set, nova will use the configurable 'max_limit' (1000 by default). Although older microversions will not accept these new query parameters, they will start to enforce the max_limit and results may be truncated as a result. Consider using the new microversion to avoid DoS-like usage requests and potentially truncated responses.
With this update, different domain names can be used for the public and the internal networks.  To set domain names per network, use the following heat template parameters:

* CloudName: The DNS name of this cloud, for example:
      'ci-overcloud.tripleo.org'
* CloudNameInternal: The DNS name of this cloud's internal API endpoint, for example:
      'ci-overcloud.internalapi.tripleo.org'
* CloudNameStorage: The DNS name of this cloud's storage endpoint, for example:
      'ci-overcloud.storage.tripleo.org'
* CloudNameStorageManagement: The DNS name of this cloud's storage management endpoint, for example:
      'ci-overcloud.storagemgmt.tripleo.org'
* CloudNameCtlplane: The DNS name of this cloud's control plane endpoint, for example:
      'ci-overcloud.management.tripleo.org'
With this update, the user interface is now partially internationalized and available in Japanese and Simplified Chinese. Note that only the interface itself is internationalized at this stage. The strings that come from other services such as the parameters, templates, and environments for the TripleO Heat Templates, the validations, and the notifications are not yet internationalized.
Recent enhancements to the director requires changes to network interface configuration templates. The NIC configuration templates now use a script that calls the 'os-net-config utility' to configure the network on the overcloud nodes. There are three major changes to the NIC config templates:

* The 'OsNetConfigImpl' resource changed from a 'OS::Heat::StructuredConfig' resource type to 'OS::Heat::SoftwareConfig'. In addition, the resource now stores the 'network_config' property as a blob of text and passes the blob to the 'run-os-net-config.sh' script using the 'str_replace' (string replace) function. For example:

----
resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: ../../scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
----

* The {get_input: <input>} constructor defined a default external bridge and interface. Now there are two special string values that substitute for the external bridge and interface. These are 'bridge_name' and 'interface_name' respectively. Instead of using '{get_input: bridge_name}' or '{get_input: interface_name}', use 'bridge_name' or 'interface_name'. For example:

----
              - type: ovs_bridge
                name: {get_input: bridge_name}
----
becomes:
----
              - type: ovs_bridge
                name: bridge_name
----

* The 'network_config' no longer uses curly braces. Instead, the {get_param: <param>} construct moves to a sub-level underneath the value being defined. For example:
----
                dns_servers: {get_param: DnsServers}
----
becomes:
----
                dns_servers:
                  get_param: DnsServers
----

See more examples in the "Network Isolation" chapter of the Advanced Overcloud Customizations guide.
With this update, Wake-On-LAN and AMT drivers have been removed from Ironic as they do not have, and are not planned to have, a third-party CI. They are still available from the unsupported ironic driver collection, found in the ironic-staging-drivers repository. If your ironic installation is using any driver based on those, you must install ironic-staging-drivers and change the driver on the affected nodes according to following list:

agent_amt -> pxe_amt_agent
pxe_amt -> pxe_amt_iscsi
agent_wol -> pxe_wol_agent
pxe_wol -> pxe_wol_iscsi
Because SELinux policies concerning launching instances with DPDK enabled are incomplete, launching instances using DPDK with SELinux in enforcing mode will cause the launch to fail and AVC denials will appear in /var/log/audit/audit.log* concerning openvswitch and svirt.

As a workaround, set SELinux to permissive on each compute node where DPDK is utilized as documented in section 4.4.1.2 here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Working_with_SELinux-Changing_SELinux_Modes.html#sect-Security-Enhanced_Linux-Enabling_and_Disabling_SELinux-Disabling_SELinux

This will allow DPDK-enabled virtual machines to launch. This is a workaround and is expected to be temporary while the issue is investigated further.
Problem in detail:
In OSP10 (OvS2.5), following are the issues:
1) tuned is configured with wrong set of CPUs. Expected configuration is NeutronDpdkCoreList + NovaVcpuPinSet, but it has been configured as HostCpusList. 
2) In post-config, the -l of DPDK_OPTIONS is set as 0 and NeutronDpdkdCoreList is configured as pmd-cpu-mask

What needs to be corrected after update, manually?
1) Add the list of cpus to be isolated, which is NeutronDpdkCoreList + NovaVcpuPinSet to the tuned conf file.

TUNED_CORES="<list of CPUs"
sed -i 's/^isolated_cores=.*/isolated_cores=$TUNED_CORES/' $tuned_conf_path
tuned-adm profile cpu-partitioning

2) lcore mask after the update will be set to 0. Get the cpu mask with get_mask code from the first-boot script [1].
LCORE_MASK="<mask value output of get_mask"
ovs-vsctl --no-wait set Open_vSwitch . other-config:dpdk-lcore-mask=$LCORE_MASK
For security reasons, the Overcloud only allows SSH key-based access by default. You can set a root password on the disk image for the overcloud using the virt-customize tool, which is found in the Red Hat Enterprise Linux Extras channel. After installing the tool and downloading the Overcloud images, use the following command to change the root password:

$ virt-customize -a overcloud-full.qcow2 --root-password password:<my_root_password>

Perform this operation prior to uploading the images into glance with the "openstack overcloud image upload" command.
Only NICs which have a live connection to a switch port will be counted in the numbered NIC abstractions (nic1, nic2, etc). As a workaround, the director includes a script that pings the first controller on all interfaces from each node. If a node has a link disconnected at deployment time, this is detected so that it can be corrected. Another possible workaround is to use a mapping file for each host, which has a mapping of NIC number to physical NIC. If one or more Overcloud nodes do not configure correctly due to a down link, this is now detected and the Overcloud can redeploy.
Discovery fails if multiple network interfaces on a node are connected to the Provisioning network. Only one interface can connect to the Provisioning network. This interface cannot be part of a bond.
Pacemaker continuously crashes when the fencing device name and the host name are the same. To avoid this problem, add the "fence-" prefix or the "-fence" suffix to the name of the fencing device. With the names configured like this, the cluster works without errors.
When you enter the `openstack stack delete` command while the nodes are still being deployed, it is possible that they remain in that being-deployed state and will not be deleted. Consequently, you will not be able to deploy any new nodes onto the space, blocked by the undeleted nodes. To avoid this situation, wait until all the nodes have been deployed completely, before entering the `openstack stack delete` command. Alternatively, you can manually delete the nodes with the `nova delete <node>` command.
The 'openstack overcloud stack update' command has a lengthy startup time. The command can take a couple of minutes for an indication the command is working. This is normal behavior.
To implement the security groups trunk feature with neutron-openvswitch-agent, openvswitch firewall driver is required. This driver currently contains a bug 1444368 where ingress traffic is wrongly matched if there are two ports with same MAC address on different network segment on the same compute node.

As a result, if a subport has the same MAC address as its parent port, ingress traffic won't be matched correctly for one of the ports.

A workaround to achieve correctly handled traffic is to disable port-security on the parent port and subports.

For example, to disable port security on port with UUID 12345, you need to remove security groups associated with the port:
 openstack port set --no-security-group --disable-port-security 12345

Note that no security groups rules will be applied to that port and traffic will not be filtered or protected against ip/mac/arp spoofing.
A race condition may occur between Puppet and MongoDB services. Consequently, scaling out nodes running the MongoDB database fails and the overcloud stack will not update. Running the same deployment command again makes the MongoDB nodes scale out successfully.
Currently, the Red Hat OpenStack Platform director 10 with SRIOV overcloud deployment fails when using the NIC IDs (for example, nic1, nic2, nic3 and so on) in the compute.yaml file.

As a workaround, you need to use NIC names (for example, ens1f0, ens1f1, ens2f0, and so on) instead of the NIC IDs to ensure the overcloud deployment completes successfully.
Under certain circumstances, such as when OVS is upgraded, or when the network service is restarted, the OVS bridges were torn down and rebuilt. Consequently, the existing network flows were interrupted when this happened, causing network traffic to stop forwarding until the flows were rebuilt. This can take some time in a complex deployment.

In order to avoid any possible downtime, the control plane networks should not be placed on an OVS bridge. The Control Plane (Provisioning), Internal API, and Storage Management networks should instead be dedicated interfaces or VLAN interfaces that are not on a bridge. For instance, one interface or bond could contain the control plane VLANs, while another interface or bond can be placed on an OVS bridge for tenant network data.

As long as the control plane interfaces are not on an OVS bridge, any network downtime will be limited to the Tenant data plane.
Processing parameters, environments and templates is slightly different on the CLI than it is in the UI.
Consequently, the passwords generated automatically by the UI cannot be changed from the templates. If you want to use custom passwords, you have to set them manually in the UI as a parameter in the overall deployment configuration or by editing the role card. 
Alternatively, you can create a plan without auto-generated passwords by entering the '$ openstack overcloud plan create <my_plan> --disable-password-generation' on the CLI.  You will have to provide the passwords explicitly by using templates or manually through the UI.
Running the 'openstack overcloud deploy' command replaces the default 'overcloud' plan. If a user creates an overcloud with the CLI, deletes it, then creates a new overcloud with the web UI, the web UI uses the 'overcloud' plan from the CLI deployment. This can cause the web UI to include unwanted parameters from the previous overcloud deployment. As a workaround:

1. Ensure the 'user-environment.yaml' environment file is disabled when deploying a new overcloud.
2. Upload a new version of the plan (from the '/usr/share/openstack-tripleo-heat-template').
The director requires nodes in a managed state before running introspection. Although newly registered nodes are set to 'manageable' in the director's web UI, no option currently exists in the web UI to switch the nodes back to 'manageable' in case users require introspection at a later date. As a workaround, use the 'openstack baremetal node manage' command to switch the nodes to 'manageable' state.
Invalid cache files may cause os-collect-config to report 'ValueError: No JSON object could be decoded' and the service will fail to start. The cache files located in '/var/lib/os-collect-config/' should be valid json files. If they are are of size 0 or contain invalid json, remove the invalid files from '/var/lib/os-collect-config', otherwise they may prevent os-collect-config from starting.
Customers who upgraded from Red Hat OpenStack Platform 9 to version 10 are advised to wait for the first asynchronous release before upgrading to Red Hat OpenStack Platform 11, which will fix this known issue. The first asynchronous release typically happens within a few days of the GA release.
In Highly Available IPv6 deployments, virtual IPs used for RabbitMQ may move between controller hosts during an upgrade. A bug in the creation of these IPv6 IPs causes them to be used as source addresses for RabbitMQ's connections. As a result, RabbitMQ will crash and may be unable to automatically recover its cluster.

To return to normal operation, restart RabbitMQ on the affected controller hosts, as well as any services which depend on RabbitMQ and do not automatically reconnect.
Customers who upgraded from Red Hat OpenStack Platform 9 to version 10 are advised to wait for the first asynchronous release before upgrading to Red Hat OpenStack Platform 11, which will fix this known issue. The first asynchronous release typically happens within a few days of the GA release.
A design flaw issue was found in the Red Hat OpenStack Platform director use of TripleO to enable libvirtd based live migration. TripleO did not have support for secure live migration and no additional steps were taken to lock-down the libvirtd deployment by director. Libvirtd is deployed by default (by director) listening on 0.0.0.0 (all interfaces) with no-authentication or encryption. Anyone able to make a TCP connection to any compute host IP address, including 127.0.0.1, other loopback interface addresses or in some cases possibly addresses that have been exposed beyond the management interface, could use this to open a virsh session to the libvirtd instance and gain control of virtual machine instances or possibly take over the host.

Note that without the presence of additional flaws, this should not be accessible from tenant or external networks.

Users who are upgrading to Red Hat OpenStack Platform 11 from Red Hat OpenStack Platform 10 should first apply the relevant update that resolves this issue.

Red Hat OpenStack Platform 11 already contains this update as of general availability and no subsequent update is required.

For more information about this flaw and the accompanying resolution, see https://access.redhat.com/solutions/3022771.
If using a standalone Keystone node on OpenStack Platform 10, 'openstack-gnocchi-statsd' does not start correctly. This is because 'gnocchi' and 'keystone' services activate on the same step, which causes a race condition. 'gnocchi' fails authentication but does not retry. This issue is addressed in BZ#1447422.

The failed 'openstack-gnocchi-statsd' service causes OpenStack Platform 11 pre-upgrade check to fail, which means upgrades from OpenStack Platform 10 to 11 also fail if using a standalone Keystone role. As a work around, restart 'openstack-gnocchi-statsd' service on the overcloud before starting any upgrade steps. This enables the service correctly and allows for a successful upgrade. This only applies to OpenStack Platform 10 with a standalone Keystone node and does not impact other upgrade scenarios.
When using Red Hat Ceph Storage as a back end for both Block Storage (cinder) volumes and backups, any attempt to perform an incremental backup will result in a full backup instead, without any warning.
OpenStack command-line clients that use `python-requests` can not currently validate certificates that have an IP address in the SAN field.
The image_path parameter is no longer used. This update removes it from the undercloud configuration file.
The VPNaaS feature is deprecated with Red Hat OpenStack Platform 11 and is expected to be removed with Red Hat OpenStack Platform 12.
Neutron's Linux Bridge ML2 driver and agent are being deprecated with Red Hat OpenStack Platform 11 and are expected to be removed with Red Hat OpenStack Platform 12. The Open vSwitch (OVS) plug-in is the one deployed by default by the OpenStack Platform director, and is recommended by Red Hat for general usage.
The Ceilometer API service is deprecated in Red Hat OpenStack Platform 11. It is replaced by the Gnocchi, Aodh, and Panko APIs respectively. Users should begin to move away from the Ceilometer API and use the service APIs instead. In Red Hat OpenStack Platform 11, the Ceilometer API is installed and configured by default. In future releases, this API will be disabled by default, with the option to enable it only if required.
As of this release, Glance API V1 is no longer supported or available.
This update adds a new user details page to the dashboard.  As a result you can click on the user ID in the Action Log to be taken directly to the user details page.
This update adds a new user details page to the dashboard.  As a result you can click on the user ID in the Action Log to be taken directly to the user details page.
This enhancement provides configuration for OpenStack Load Balancing as a Service (octavia) through the Red Hat OpenStack Platform director.
A high memory consumption was observed, especially in large environments, which often led to out-of-memory issues. The main culprit was neutron-ns-metadata-proxy process, responsible for proxying metadata requests from the VM to Nova.

neutron-ns-metadata-proxy is now replaced by haproxy which has a more lightweight memory footprint.
The OS::Nova::ServerGroup resource now allows you to use the 'soft-affinity' and 'soft-anti-affinity' policies. This is in addition to the 'affinity' and 'anti-affinity' policies.
To use SR-IOV physical function (PF) and virtual functions (VFs) in the same environment, add the 'nm_controlled' and 'hotplug' parameters to the SR-IOV PF configuration in your compute.yaml heat template:

 -type: interface
  name: nic6
  use_dhcp: false
  nm_controlled: true
  hotplug: true

When an OpenStack instance that was using a direct physical function is destroyed, the PCI device is released back to OpenStack and the host system. The root PCI device is then configured to support the number of virtual functions configured during deployment. This process involves the coordination of the host operating system, NetworkManager and OpenStack and may require a short interval of time before the virtual functions are available for use.
Red Hat OpenStack Platform 11 ships with many fewer API workers for each service than in the previous version. Having fewer workers lowers the noise, but also lowers the performance of API response times.
Invalid cache files may cause os-collect-config to report 'ValueError: No JSON object could be decoded' and the service will fail to start. The cache files located in '/var/lib/os-collect-config/' should be valid json files. If they are are of size 0 or contain invalid json, remove the invalid files from '/var/lib/os-collect-config', otherwise they may prevent os-collect-config from starting.
In Highly Available IPv6 deployments, virtual IPs used for RabbitMQ may move between controller hosts during an upgrade. A bug in the creation of these IPv6 IPs causes them to be used as source addresses for RabbitMQ's connections. As a result, RabbitMQ will crash and may be unable to automatically recover its cluster.

To return to normal operation, restart RabbitMQ on the affected controller hosts, as well as any services which depend on RabbitMQ and do not automatically reconnect.
A database upgrade issue hindered the OpenStack Networking (neutron) upgrade. This hindered the upgrade from OpenStack Platform 10 to 11. This fix corrects the neutron database upgrade issue.

This issue affects customers who previously upgraded from OpenStack Platform 9 to 10 and now aim to upgrade to OpenStack Platform 11.
OpenStack Compute (nova) provides both versioned and unversioned notifications in RabbitMQ. However, due to the lack of consumers for versioned notifications, the  versioned notifications queue grows quickly and causes RabbitMQ failures. This can hinder Compute operations such as instance creation and flavor creation. Red Hat is currently implementing fixes for RabbitMQ and director:

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

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

https://access.redhat.com/solutions/3139721
When using Red Hat Ceph Storage as a back end for both Block Storage (cinder) volumes and backups, any attempt to perform an incremental backup will result in a full backup instead, without any warning.
Previously, during the Red Hat OpenStack Platform 11 deployment, there is a race condition where, on occasion the ceilometer-upgrade runs at the same time as Apache is restarted due to other services being configured in the same step. This resulted in the ceilometer-upgrade to fail as it could not authenticate with the Identity service, as Apache was still not in the active state and aborting the deployment as a failure. 

With this update, as a workaround, when this happens you need to restart the overcloud deploy from where it fails and the deploy should get past this race condition and proceed with the deployment as normal.  As a result, the deployment should be successful instead of failing with an error.
RHEL overcloud images contain tuned version 2.8.
In OVS-DPDK and SR-IOV deployments, tuned install and activation is done through the first-boot mechanism.

This install and activation fails, as described in https://bugzilla.redhat.com/show_bug.cgi?id=1488369#c1

You need to reboot the compute node to enforce the tuned profile.
As of this release, Glance API V1 is no longer supported or available.
The store_events option in undercloud.conf has been deprecated and is no longer supported. This option has been removed from the configuration.
The undercloud stack rc file is a Keystone v2 rc. Previously, when switching from a v3 rc file (such as the v3 overcloudrc), some of the v3 environment variables would still be present. As a result, Keystone authentication may not work correctly.

With this release, all OpenStack-related environment variables are cleared in stackrc before the undercloud values are set.  As a result, variables from a previous rc file can no longer be present in the environment after sourcing stackrc, so Keystone authentication works correctly.

The image_path parameter is no longer used. This update removes it from the undercloud configuration file.

In certain situations, the undercloud virtual IPs were not correctly validated due to an error in the validation logic. Consequently, the undercloud could be deployed with incorrect virtual IPs. The error has been fixed. Now the virtual IPs are correctly validated. Any problem in virtual IP configuration is discovered before actual deployment.

Previously, concurrent requests to create a volume from the same image could result in multiple entries in the Block Storage service's image cache. This resulted in duplicated image cache entries for the same image, which wasted space.

This update adds a synchronization lock to prevent this. The first request to create a volume from an image will be cached, and all other requests will use the cached image.

With this enhancement, `glance-manage db purge` can now remove rows that are less than one day old. This was added because operators may need to run this operation on a regular basis.
As a result, the value of the `age_in_days` option can be set to `0`.

The Time Series Database as a Service (gnocchi) and Aodh API endpoints now expose a `/healthcheck` HTTP endpoint on the REST API. Requesting this endpoint allows you to check the status of the service, and does not require authentication.

Previously, when a pre-update hook was set on a resource that was in a FAILED state, the Orchestration service recorded an event indicating the hook was active. The service would then immediately create a replacement resource without waiting for the hook to be cleared by the user. As a result, the tripleoclient service believed the hook to be pending (based on the event), but fail upon trying to clear it as the replacement resource did not have a hook set. This, in turn, prevented the director from completing an overcloud update with the following message:

    ERROR: The "pre-update" hook is not defined on SoftwareDeployment
    "UpdateDeployment"

This also affected other client-side applications that used hooks. In the director, this could have also resulted in UpdateDeployment executing on two Controller nodes simultaneously, instead of serialized so that only one Controller is updated at a time.

With this release, the Orchestration service now pauses until the hook is cleared by the user, regardless of the state of the resource. This allows director overcloud updates to complete even when there is an UpdateDeployment resource in a FAILED state.

Previously, while the Orchestration service could reset the status of resource when the state of the stack was incorrect, the service failed to do so when an update was retriggered. This resulted in resources being stuck in progress, which required database fixes to unblock the deployment.

With this release, the Orchestration service now sets the status of all resources when it sets the status of the stack. This prevents the resources from getting stuck in progress, allowing operations to be retried successfully.

This update provides enhancements to the CephFS Native Driver in conjunction with the core OpenStack File Share Service (manila) infrastructure. The CephFS Native driver now supports read-only shares and improves recovery mode by deleting backend rules not in the 'access_list'.

With this enhancement, you can now enable the creation of non-public shares in the Dashboard.
You can configure Dashboard to hide the checkbox that enables users to mark shares as public during the creation process. The default option will be to create shares as private without the box checked.

To implement the security groups trunk feature with neutron-openvswitch-agent, openvswitch firewall driver is required. This driver currently contains a bug 1444368 where ingress traffic is wrongly matched if there are two ports with same MAC address on different network segment on the same compute node.

As a result, if a subport has the same MAC address as its parent port, ingress traffic won't be matched correctly for one of the ports.

A workaround to achieve correctly handled traffic is to disable port-security on the parent port and subports.

For example, to disable port security on port with UUID 12345, you need to remove security groups associated with the port:
 openstack port set --no-security-group --disable-port-security 12345

Note that no security groups rules will be applied to that port and traffic will not be filtered or protected against ip/mac/arp spoofing.

On DVR setups, the 'test_add_list_remove_router_on_l3_agent' from the 'test_l3_agent_scheduler.py' would not finish successfully. The testing procedure tried to bind a network interface to an L3 agent, although the interface had been bound to one previously, when a new router was created.
The problem has been fixed. Now the interface will not be added to the router and assigned to the L3 agent until the test does so. As a result, the test finishes successfully.

This enhancement adds the ability to automatically reschedule load balancers from LBaaS agents that the server detects as dead. Previously, load balancers could be scheduled and realized across multiple LBaaS agents, however if a hypervisor died, the load balancers scheduled
to that node would cease operation. With this update, these load balancers will be automatically rescheduled to a different agent. This feature is disabled by default and managed using `allow_automatic_lbaas_agent_failover`.

This enahncement implements the 'ProcessMonitor' class in the 'HaproxyNSDriver' class (v2), This class utilizes the 'external_process' module to monitor and respawn HAProxy processes if and when needed. The LBaaS agent (v2) loads 'external_process' related options and take a configured action when HAProxy dies unexpectedly.

This release adds pagination support to avoid resource-consuming usage requests on systems with a large number of instances. The v2.40 microversion of the nova API simple-tenant-usage endpoints use new optional query parameters 'limit' and 'marker' for pagination. The 'marker' option sets the starting point and the 'limit' option sets the number of records to be displayed after the starting point. If 'limit' is not set, nova will use the configurable 'max_limit' (1000 by default). Although older microversions will not accept these new query parameters, they will start to enforce the max_limit and results may be truncated as a result. Consider using the new microversion to avoid DoS-like usage requests and potentially truncated responses.

This update adds support for the version 5.1.0 MapR plugin.

Because SELinux policies concerning launching instances with DPDK enabled are incomplete, launching instances using DPDK with SELinux in enforcing mode will cause the launch to fail and AVC denials will appear in /var/log/audit/audit.log* concerning openvswitch and svirt.

As a workaround, set SELinux to permissive on each compute node where DPDK is utilized as documented in section 4.4.1.2 here:

Permanent Changes in SELinux States and Modes

This will allow DPDK-enabled virtual machines to launch. This is a workaround and is expected to be temporary while the issue is investigated further.

When deleting a node in heat, the deletion command finished and the prompt returned, although the process was still going on in the background. If another command followed immediately, a conflict would occur and the consequent command would fail. The behavior of the process has been changed. Now, the prompt will only return, when the process finishes completely.

Automatic fencing setup can be used in director for easier High Availability deployments and upgrades. To benefit from the new feature, use the 'overcloud generate fencing' command.

If stopping the neutron-openvswitch-agent service, the stopping process sometimes took too long to exit gracefully and was killed by systemd. In this case, a running neutron-rootwrap-daemon remained in the system, which prevented the neutron-openvswitch-agent service to restart.
The problem has been fixed. Now, an rpm scriplet detects the orphaned neutron-rootwrap-daemon and terminates it. As a result, the neutron-openvswitch-agent service starts and restarts successfully.

With this release, 'clustercheck' will only run on nodes specified in the 'wsrep_cluster_address' option of Galera. This change was implemented to take into account use cases where Galera is run on a dedicated node (as is made possible with composable roles). Previously, during minor updates 'clustercheck' ran on all nodes running pacemaker, assuming Galera was also on the same node.

The director set the 'tcp_list_options' stanza twice in '/etc/rabbitmq/rabbitmq.config'. This caused no adverse effects but could cause confusion in the future. This fix removes the redundant stanza. Only one 'tcp_list_options' stanza now appears in the configuration file.

It is now possible to use puppet hieradata to set the max_files and max_processes for QEMU instances spawned by libvirtd. This can be done through an environment file containing the appropriate puppet classes. For example, to set the max_files and max_processes to 32768 and 131072 respectively, use:

parameter_defaults:
  ExtraConfig
    nova::compute::libvirt::qemu::max_files: 32768
    nova::compute::libvirt::qemu::max_processes: 131072

This update also sets these values as the default, since QEMU instances launched by libvirtd might consume a large number of file descriptors or threads. This depends on Compute guest hosted on each compute node and of Ceph RBD images each instance attaches to. It is necessary to be able to configure these limits in large clusters.

With these new default values, the Compute service should be able to use more than 700 OSDs. This was previously identified as the limit imposed by the low number of max_files (originally 1024).

OpenStack Platform 10 included a broken Big Switch agent configuration. Deploying Big Switch agents with the provided heat templates resulted in deployment failures. This fix updates the heat templates to properly deploy Big Switch agents. Now the director correctly deploys the Big Switch agent service in composable roles.

The default memory configuration for Memcached was 95 per cent of total available RAM, which could lead to resource contention. This fix lowers the default value to 50 per cent of total available RAM. You also can now configure this value using the 'MemcachedMaxMemory' setting. This helps reduce possible resource conflicts.

A bug in the overcloud package update script caused cluster services to always restart even if no packages were available for update. This fix corrects the check that determines if there are pending package updates. If no packages updates are available, the yum update script exits and does not restart cluster services.

For security reasons, the Overcloud only allows SSH key-based access by default. You can set a root password on the disk image for the overcloud using the virt-customize tool, which is found in the Red Hat Enterprise Linux Extras channel. After installing the tool and downloading the Overcloud images, use the following command to change the root password:

$ virt-customize -a overcloud-full.qcow2 --root-password password:my_root_password

Perform this operation prior to uploading the images into glance with the "openstack overcloud image upload" command.

The 'tuned-profiles-cpu-partitioning' package is now pre-installed in the 'overcloud-full.qcow2' image. For DPDK deployments, this package is necessary to help tune hosts and isolate CPU usage. The director contains appropriate firstboot scripts to enable the 'tuned' service with the necessary arguments.

Currently, the Red Hat OpenStack Platform director 10 with SRIOV overcloud deployment fails when using the NIC IDs (for example, nic1, nic2, nic3 and so on) in the compute.yaml file.

As a workaround, you need to use NIC names (for example, ens1f0, ens1f1, ens2f0, and so on) instead of the NIC IDs to ensure the overcloud deployment completes successfully.

When upgrading or deploying a Red Hat OpenStack Platform environment integrated with an external Ceph Storage Cluster from an earlier version (that is, Red Hat Ceph Storage 1.3), it is necessary to enable backwards compatibility. To do so uncomment the following line in environments/puppet-ceph-external.yaml during upgrade or deployment:

parameter_defaults:
  # Uncomment if connecting to a pre-Jewel or RHCS1.3 Ceph Cluster
  RbdDefaultFeatures: 1

This release features the necessary puppet modules for deploying CephFS. This allows you to deploy the OpenStack Shared File System service (openstack-manila) with a CephFS back-end through the director.

Previously, sometimes a deployment failed with the following error:
	  Error: /Stage[main]/Pacemaker::Corosync/Exec[Start Cluster tripleo_cluster]/returns: change from notrun to 0 failed: /sbin/pcs cluster start --all returned 1 instead of one of 0

With this update, a small race condition where puppet pacemaker could fail during cluster setup was closed. As a result, the deployment works correctly without errors.

Previously, all pacemaker services had to be part of the same role.

With this update, a new feature allows you to use composable roles with pacemaker managed services. This feature is needed in order to scale out pacemaker managed services on more and different nodes.

Previously, the OpenStack Dashboard service was configured in the wrong step of the deployment, resulting in horizon being temporarily unavailable during deployments and leading to additional 'httpd' service restarts.

With this update, the OpenStack Dashboard configuration is fixed to occur at the same time as the rest of the 'httpd' configuration. As a result, horizon does not become temporarily unavailable when running the overcloud.

The administrator needs to record the user credentials during the volume transfer operation and doing so by hand is inconvenient.

With this update, a new button to download the credentials has been added to the volume transfer screen for saving the information easily. This allows the administrators to download and save a CSV file locally on their computer with the click of a button.

To avoid memory bloat issues in the nova-api workers, pagination logic has been added to the simple-tenant-usage API extension.

Previously, improper handling of the user IDs containing underscore in the code made it impossible to update project/domain members when the user IDs contained underscores.

With this update, the code that handles the user IDs has been corrected to properly handle underscores. As a result, the project/domain members can now be updated even if they contain underscores.

After the optimization of event retrieval process, the 'openstack stack hook poll' command stopped returning pending hooks, even if they existed and should be returned. The problem was fixed. Now pending hooks are returned correctly.

The '--os-interface' switch was ignored by 'openstack network' commands. Consequently, all such commands used the 'public' endpoint, although other interfaces were specified. The support for the switch has been added. Now the 'openstack network' commands correctly use the endpoint specified in '--os-interface' switch.

The Remote Procedure Call (RPC) message acknowledgement in Oslo Messaging was not thread-safe. Consequently, a race condition caused an RPC timeout in Ceilometer. The message acknowledgement in Oslo Messaging has been fixed. Now, Ceilometer responds correctly.

The Oslo Messaging did not initialize its configuration properly. As a result, the 'nova-manage' client failed during startup. The error has been fixed. Now 'nova-manage' starts correctly.

Previously, a failed update or upgrade would return an exit value of 0, so it was not possible to test for success based upon this value. With this update, a failed update or upgrade will throw an exception to signify to OpenStackClient that there is an error condition. As a result, OpenStackClient will only return an exit value of 0 on success, and a non-zero value after an error.

The 'openstack overcloud image upload' ignored the '--image-path' argument when uploading or updating overcloud images. Consequently, only images in the working directory could be used. The support for the '--image-path' argument has been added. Now images from different directories, specified by the argument, can be uploaded flawlessly.

pacemaker continuously crashes when the fencing device name and the host name are the same. To avoid this problem, add the "fence-" prefix or the "-fence" suffix to the name of the fencing device. With the names configured like this, the cluster works without errors.

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

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

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

Release Notes

Release details for Red Hat OpenStack Platform 11

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 Supported Operating Systems

1.8. Hypervisor Support

1.9. Content Delivery Network (CDN) Channels

1.10. Product Support

Chapter 2. Top New Features

2.1. Red Hat OpenStack Platform Director

2.2. Block Storage

2.3. Compute

2.4. Dashboard

2.5. Identity

2.6. Image Service

2.7. OpenStack Networking

2.8. Shared File System

2.9. Telemetry

2.10. High Availability

2.11. Operations Tooling

2.12. Bare Metal Provisioning Service

2.13. OpenStack Integration Test Suite Service

2.14. OpenStack Data Processing Service

2.15. Technology Previews

2.15.1. New Technology Previews

2.15.2. Previously Released Technology Previews

Chapter 3. Release Information

3.1. Red Hat OpenStack Platform 11 GA

3.1.1. Enhancements

3.1.2. Release Notes

3.1.3. Known Issues

3.1.4. Deprecated Functionality

3.2. Red Hat OpenStack Platform 11 Maintenance Releases

3.2.1. Enhancements

3.2.2. Release Notes

3.2.3. Known Issues

3.2.4. Deprecated Functionality

Chapter 4. Technical Notes

4.1. RHEA-2016:1245 — Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory

Legal Notice

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