Release notes

By default, live migration uses one network connection to transfer an instance to a destination Compute node. Factors such as single-threaded TLS speed can limit performance. To increase migration speed, enable multiple connections per live migration.

Jira:RHOSSTRAT-1139

You can physically replace an NVMe device that uses PCI passthrough without interrupting running instances or affecting the data plane host.

Jira:RHOSSTRAT-910

Due to a bug in nova-operator, if notificationsBusInstance is configured in the nova section of the OpenStackControlPlane custom resource (CR) to point to a RabbitMqCluster CR, and a pod in that cluster is restarted, then nova-operator reconfigures all Compute services twice. This results in unnecessary service downtime.

Temporary workaround:

Jira:OSPRH-26269

The image properties weigher does not take the os_version or os_admin_user properties into account when calculating the raw weights when these properties are included in the configuration.

Jira:OSPRH-21740

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

Before this update, an empty node set prevented the completion of the minor update process. With this update, an empty node set no longer prevents the minor update process from completing successfully.

Jira:OSPRH-25612

Before this update, when a control plane route failed it was not included in the OpenStackControlPlane CR conditions list, which made it difficult to identify the root cause. With this update, the OpenStackControlPlane CR conditions list has been extended to include the status of the routes.

Jira:OSPRH-8984

Red Hat OpenStack Services on Openshift (RHOSO) uses metal3 for provisioning unprovisioned data plane nodes. An error state occurs when you must replace a node where the bootMacAddress cannot be updated. The result is that the node is stuck in a state where it must be completely removed from the deployment and provisioned as if it is a new node. If the automatedCleaningMode attribute is set automatedCleaningMode: disabled, this error state does not occur.

Workaround: When provisioning unprovisioned data plane nodes, ensure the automatedCleaningMode attribute is set to automatedCleaningMode:disabled.

Jira:OSPRH-20302

By default, RabbitMQ clusters use Quorum queues for new RHOSO deployments to provide increased data safety and high availability at the expense of a slight increase in latency.

Jira:OSPRH-21998

Starting with RHOSO 18.0.17 (Feature Release 5), you can improve the high availability of services by configuring them to better deal with temporary RabbitMQ issues by talking to each RabbitMQ pod individually.

To do so, you can configure the RabbitMQ cluster to expose each pod individually using a dedicated IP address by adding a podOverride section as shown in the following example:

rabbitmq:
  delayStartSeconds: 30
  override:
    service:
      metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.80
      spec:
        type: LoadBalancer
  podOverride:
    services:
    - metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.81
      spec:
        type: LoadBalancer
    - metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.82
      spec:
        type: LoadBalancer
    - metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.83
      spec:
        type: LoadBalancer
  persistence:     storage: 10Gi

After applying this change to the control plane you must redeploy the data plane to update all the Compute nodes.

Jira:OSPRH-21551

Starting with RHOSO 18.0.17 (Feature Release 5), you can create and manage alerts to notify you of specific conditions in your RHOSO networking operations.

For more information, see Networking alerts in Configuring observability.

Jira:RHOSSTRAT-1068

You cannot migrate from the ifcfg provider of os-net-config to the Nmstate provider with switchdev mode enabled.

Workaround: disable switchdev mode before migrating to the Nmstate provider.

Jira:OSPRH-16151

You can now upgrade in-place an OpenStack deployment from RHOSP 17.1 to RHOSO 18 by deploying a parallel control plane based on RHOSO 18 and then pointing the compute nodes to the new control plane. For more information, see Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:RHOSSTRAT-1102

You can now adopt a director-deployed Load-balancing service (Octavia) control plane service from Red Hat OpenStack Platform 17.1 to Red Hat OpenStack Services on OpenShift (RHOSO) 18.0. This feature allows you to preserve existing configurations and to ensure seamless operation in the new RHOSO environment.

For more information about adopting the Load-balancing service, see Adopting the load-balancing service in Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:RHOSSTRAT-167

Before this update, when deploying RHOSO with both the neutron-fwaas driver and log API plugins, end users experienced log creation failure. The issue is fixed and you can deploy with both the neutron-fwaas driver and log API plugins in the same neutron deployment. Note that Firewall as a Service is a Technology Preview in RHOSO 18.0.17 Feature Release 5.

Jira:OSPRH-21926

In RHOSO 18.0.17 (Feature Release 5), you can test a Technology Preview of data plane adoption of the DNS service (designate). Do not use Technology Preview features in production environments.

Jira:RHOSSTRAT-290

There is a known issue where the OVN database sync tool, neutron-ovn-db-sync-util, always reports the following warning: ValueError: driver cannot be None. This warning is caused by a regression introduced in RHOSO 18.0.17 that prevents the OVN database sync tool from syncing the OVN southbound database (SB DB).

Workaround: execute the sync tool on the OVN northbound database only by using the argument, --sync_plugin neutron_nb_sync:

Example

$ oc rsh -n openstack -c neutron-api deploy/neutron \
neutron-ovn-db-sync-util --config-file \
/usr/share/neutron/neutron-dist.conf --config-file \
/etc/neutron/neutron.conf --config-dir /etc/neutron/neutron.conf.d \
--ovn-neutron_sync_mode=log --debug --sync_plugin neutron_nb_sync

This workaround does not execute the sync tool for the SB DB. Therefore, the following checks are not executed:

Jira:OSPRH-27683

There is a known issue where the OVN database sync tool, neutron-ovn-db-sync-util, reports the following error and then crashes: No providers specified for 'FIREWALL_V2' service, exiting. This warning is caused by a regression introduced in RHOSO 18.0.17.

Workaround: you can workaround this problem by either specifying the value FIREWALL_V2 in the service_providers configuration variable, or by running the required plug-ins separately:

Example

$ oc rsh -n openstack -c neutron-api deploy/neutron \
neutron-ovn-db-sync-util --config-file \
/usr/share/neutron/neutron-dist.conf --config-file \
/etc/neutron/neutron.conf --config-dir /etc/neutron/neutron.conf.d \
--ovn-neutron_sync_mode=log --sync_plugin neutron_nb_sync --debug

This workaround does not execute the sync tool for the SB DB. Therefore, the following checks are not executed:

Jira:OSPRH-27676

In RHOSO 18.0, the RHOSO DNS service (designate) is unsupported in dynamic routing environments that use BGP. The designate-worker pods cannot configure designate-backendbind9 pods and, as a consequence, the DNS service does not work properly. The cause for this is that the worker pods try to connect to the back-end BIND 9 pods by using their common network attachment definition, with a common subnet range, which does not work properly when BGP is configured, because pods should use different subnet ranges to connect to each other. Workaround: there is no known workaround.

Jira:OSPRH-26878

There is a known issue where network traffic is erroneously coming in and out when only one firewall rule is set. This problem can occur when using Firewall as a service (FWaaS) and enabling security groups. FWaaS should only allow incoming or outgoing traffic when two rules are set.

Workaround: currently, there is no workaround.

Jira:OSPRH-26457

RHOSO administrators can enable the Rating service (cloudkitty) in the Telemetry Operator to provide chargeback and rating capabilities to RHOSO clouds.

The Rating service collects data from the RHOSO Telemetry service to generate cloud resource usage through rating reports. These reports can be consumed by external financial operations or billing systems. The Rating service does not provide a billing interface.

Jira:RHOSSTRAT-1006

The metrics.yaml configuration file defines the rating metrics to collect for a RHOSO cloud. Before this update, the Rating service did not work because the default metrics.yaml configuration file was configured for the Gnocchi collector, which is not supported. With this update, the default metrics.yaml file is updated to define the metrics that are collected by the supported collector, Prometheus.

Jira:OSPRH-23737

Before this update, the cloud admin would receive empty summaries from the Summary API. This was because the key used by the Summary API was hard coded to the string "project_id" that did not match the default key "project". With this update, the key is now configurable, enabling the cloud admin to specify the key to use for generating summaries.

Jira:OSPRH-23735

Before this update, the autoscaling controller was not reacting to changes to Alarming service (aodh) resources, such as a changed password or TLS certificate. This caused the aodh pod to continue using old configuration or data because the aodh pod had not been restarted to apply the changes. With this update, the autoscaling controller now watches for changes to the Alarming service and reacts to them by restarting the aodh pod as required to update the resources and consume the latest data.

Jira:OSPRH-22602

Before this update, topology configured for the Ceilometer service was not applied to mysqld-exporter or the kube-state-metrics agent. With this update, if you configure a topology for the Ceilometer service, it will be applied to mysqld-exporter and the kube-state-metrics agent.

Jira:OSPRH-22598

Before this update, topology configured for the Ceilometer service were not being applied because the service label was being assigned the incorrect value of "metricStorage". With this update, the service label of the Ceilometer resource is now set to the correct value.

Jira:OSPRH-22596

Before this update, Prometheus did not scrape metrics from all RabbitMQ nodes as expected. Instead, it scraped metrics only from one node at a time. The selection of that one node was not predictable.

Now, Prometheus scrapes metrics from all RabbitMQ nodes as expected.

Jira:OSPRH-21020

In RHOSO 18.0.17, the Ceilometer compute agent, ceilometer_agent_compute, fails to start because the data plane does not provision TLS certificates for the Ceilometer prometheus_exporter. This results in Prometheus being unable to scrape metrics from the Ceilometer compute agent on data plane nodes.

Workaround: Configure the missing property as customServiceConfig in the OpenStackControlPlane CR:

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack-control-plane
spec:
  telemetry:
    template:
      ceilometer:
        customServiceConfig: |
          [service_credentials]
          cafile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Jira:OSPRH-27068

The OpenStack Optimize service is not supported in multi-RHEL (Red Hat Enterprise Linux) mode. Running the Optimize service in multi-RHEL mode leads to service disruption, specifically on Compute nodes that are running on RHEL 9.2 and RHEL 9.4.

Jira:OSPRH-22853

In RHOSO 18, the Optimize service (watcher) Engine does not automatically revert failed actions when an Action Plan fails, when configured to do so by enabling the watcher_applier.rollback_when_actionplan_failed configuration option.

Workaround: Manually revert each failed action in the Action Plan. To avoid the rollback, you can diagnose and fix the root cause of the failure and then run the Audit again to propose a new solution.

Jira:OSPRH-19735

The Single Keystone Multiple OpenStacks (SKMO) multi-region deployment of RHOSO simplifies user management and configuration for multiple regions.

In standard multi-region RHOSO deployments, each region is isolated with its own Identity (keystone) and Dashboard (horizon) services. This requires separate user accounts for each region, making credential management and rotation difficult.

A multi-region Single Keystone Multiple OpenStacks (SKMO) deployment of RHOSO administrators creates a centralized Dashboard (horizon) and Identity (keystone) service to provide a single pane of glass for the simplified configuration and management of the users. Each end user has a single set of credentials and their access to every workload region can be enabled or disabled in the central region.

For more information about SKMO deployments, see Single Keystone Multiple OpenStacks deployments in Configuring security services.

Jira:RHOSSTRAT-907

In RHOSO 18.0.17 (Feature Release 5), you can test a Technology Preview of the data plane adoption of the Key Manager service (barbican) with Proteccio hardware security module (HSM) integration. Do not use Technology Preview features in production environments.

Jira:RHOSSTRAT-946

In RHOSO 18.0.17 (Feature Release 5), a technology preview is available for near Zero Downtime Password Rotation (nZDPR) that eliminates service interruptions typically caused by credential updates in RHOSO. While standard user credential authentication often fails during propagation, nZDPR utilizes application credentials that provides a configurable grace period. This allows both old and new credentials to remain valid simultaneously during the transition, ensuring continuous service availability across the control plane and the data plane while maintaining strict security compliance.

Jira:RHOSSTRAT-121

This enhancement adds support for integration with external Red Hat Ceph Storage 9.

For active/active (A/A) CephFS-NFS deployments, reserve at least one standby node in your Ceph Storage cluster for successful failover. For environments that require automated CephFS-NFS recovery without additional standby capacity, use active/passive (A/P) mode. A/A failover recovery will be enhanced in Red Hat Ceph Storage 9.1.

If you use CephFS-NFS and plan to upgrade from Red Hat Ceph Storage 8.x to 9.0.1, see the Known Issues section.

Jira:RHOSSTRAT-1040

The iSCSI daemon (iscsid) and multipath daemon (multipathd) now run directly on data plane host systems instead of in containers. This change enables additional capabilities such as booting from iSCSI disks. iSCSI multipath functionality continues to work as before for both new and existing deployments.

Jira:RHOSSTRAT-1003

The Red Hat OpenStack Services on OpenShift adoption now supports services that are configured to use the Block Storage service as a back end with FC. For more information about Block Storage service adoption, see RHOCP preparation for Block Storage service adoption in Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:RHOSSTRAT-683

Red Hat OpenStack Platform (RHOSP) 17.1 Distributed Compute Node (DCN) deployments can now adopt to RHOSO 18. The adoption procedure maps TripleO stacks to data plane node sets with site-specific network configurations. This update supports DCN deployments that have edge sites with Red Hat Ceph Storage or edge sites without storage.

Jira:RHOSSTRAT-616

With this update, administrators can configure a default retention period for shares when using the NetApp ONTAP driver with share server management (driver_handles_share_servers set to True) in the Shared File Systems service (manila).

ONTAP firmware version 9.11 and later enables volume retention by default, which might not suit all cloud use cases. Use the netapp_delete_retention_hours configuration option to specify how long in hours a deleted share remains on the storage system before being purged. Set the configuration option to 0 to disable retention. This option only applies when the Shared File Systems service manages the share server life cycle.

Jira:OSPRH-20802

Before this update, setting a quota limit to -1 (unlimited) and attempting to create a large volume caused quota reservation overflow due to database integer limits. This prevented users from creating new volumes due to database errors. With this update, the Block Storage service (cinder) includes quota overflow detection to prevent database errors and allow volume operations to complete successfully.

Jira:OSPRH-26064

Before this update, when you resized an NFS volume that had snapshots, the operation failed to update the virtual size of the active image file, causing a discrepancy between the Block Storage service (cinder) database and the actual image size. This update ensures that the NFS driver updates both the Block Storage service database and the virtual size of the active image during resize operations with snapshots.

Jira:OSPRH-25725

Before this update, using openstack image set --project <project_id> --accept <image_id> to accept a shared image incorrectly transferred image ownership to the accepting project. The original image owner lost access to the image. With this update, accepting shared images only updates the membership status and preserves the original image ownership.

Jira:OSPRH-23809

Before this update, credential rotation could produce corrupted URLs in the database when AWS secret access keys contained forward slashes (/). The URL parser misinterpreted forward slashes as path delimiters, causing S3 image downloads to fail with authentication errors. With this update, the Image service (glance) correctly parses these URLs.

Jira:OSPRH-23785

Before this update, when you repeatedly stopped and started instances on data plane nodes with iSCSI multipath storage, instance starts frequently failed. This issue occurred because of a race condition between volume disconnect and reconnect operations. This update improves multipath device management during these operations, and instance starts now complete successfully when using iSCSI multipath-enabled storage.

Jira:OSPRH-23115

Before this update, if a block device was unavailable in /dev/, the disk image conversion utility (qemu-img convert) would create and write data without checking if the destination device existed. This resulted in a file being written to an unavailable device, leading to data loss. This update introduces a check for the existence of the destination device before running qemu-img convert, preventing file creation in /dev/ when a block device is unavailable.

Jira:OSPRH-20818

Before this update, the RHEL system.devices file that is used for Logical Volume Management (LVM) device management in the RHOSO 18 data plane was not always present, and the file must be present for LVM filtering to mask Block Storage service (cinder) volumes. With this update, the system.devices file is created if it is absent.

Jira:OSPRH-20217

Before this update, the cinder-manage quota check and cinder-manage quota sync commands failed when no project-id argument was specified, preventing accurate quota management in the Block Storage service (cinder). This update corrects the error in quota management commands, ensuring accurate management of quota usage, even when no project-id argument is specified.

Jira:OSPRH-19057

Upgrading from RHCS 8.x to RHCS 9.0.1 causes the CephFS-NFS service to fail to start after the upgrade completes, making it unavailable to all clients. If you use CephFS-NFS with RHCS 8.x in your RHOSO deployment, delay upgrading RHCS until a fix is available.

Jira:OSPRH-27297

When you upload an image to the Image service (glance) that is larger than the configured image size limit (image_size_total), the upload succeeds because the Image service does not verify the image size before upload. When the image is uploaded and stored, the Image service determines the image size, which might exceed the quota. However, the Image service rejects any subsequent uploads because the quota is exceeded.

Jira:OSPRH-20618

Updating your OpenStack service containers and Red Hat Enterprise Linux (RHEL) packages separately provides you with more control over the update process. You can identify and troubleshoot issues more easily by isolating issues to specific packages, and reduce downtime during the update.

You can update your Red Hat OpenStack Services on OpenShift (RHOSO) Compute nodes that are running RHEL 9.2, 9.4, or 9.6 in the following phases:

Jira:RHOSSTRAT-865

Kernel live patching (kpatch) for RHOSO environments is now generally available. Previously, the kpatch instructions were provided as a Technology Preview.

With this feature, you can apply critical security updates and bug fixes to the kernel without requiring a system reboot. You cannot use this feature to apply custom live patches or third-party live patching solutions.

For more information about enabling kpatch, see Enabling kernel live patching on Compute nodes in Updating your environment to the latest maintenance release.

Jira:RHOSSTRAT-598

The update process now accommodates network controller integrations that do not use OVN. If OVN is disabled, the minor update process continues without waiting for OVN to be deployed to the data plane.

Jira:OSPRH-23103

Due to a bug in nova-operator, if notificationsBusInstance is configured in the nova section of the OpenStackControlPlane custom resource (CR) to point to a RabbitMqCluster CR, and a pod in that cluster is restarted, then nova-operator reconfigures all Compute services twice. This results in unnecessary service downtime.

Temporary workaround: 1. Remove the notificationsBusInstance configuration from the OpenStackControlPlane CR. Do not remove the notification RabbitMqCluster definition from the OpenStackControlPlane CR. 2. Gather the transport_url from the RabbitMqCluster:

+

$ oc get secret <name-rabbitmq-notifications>-default-user -o json | jq '.data | map_values(@base64d) | "rabbit://\(.username):\(.password)@\(.host):\(.port)/?ssl=1"'

+

Jira:OSPRH-26269

The image properties weigher does not take the os_version or os_admin_user properties into account when calculating the raw weights when these properties are included in the configuration.

Jira:OSPRH-21740

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

Red Hat OpenStack Services on Openshift (RHOSO) uses metal3 for provisioning unprovisioned dataplane nodes. An error state occurs when you must replace a node where the bootMacAddress cannot be updated. The result is that the node is stuck in a state where it must be completely removed from the deployment and provisioned as if it is a new node. If the automatedCleaningMode attribute is set automatedCleaningMode: disabled, this error state does not occur.

Workaround: When provisioning unprovisioned dataplane nodes, ensure the automatedCleaningMode attribute is set to automatedCleaningMode:disabled.

Jira:OSPRH-20302

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

When you upload an image to the Image service (glance) that is larger than the configured image size limit (image_size_total), the upload succeeds because the Image service does not verify the image size before upload. When the image is uploaded and stored, the Image service determines the image size, which might exceed the quota. However, the Image service rejects any subsequent uploads because the quota is exceeded.

Jira:OSPRH-20618

In RHOSO 18, the Optimize service (watcher) Engine does not automatically revert failed actions when an Action Plan fails, when configured to do so by enabling the watcher_applier.rollback_when_actionplan_failed configuration option.

Workaround: Manually revert each failed action in the Action Plan. To avoid the rollback, you can diagnose and fix the root cause of the failure and then run the Audit again to propose a new solution.

Jira:OSPRH-19735

The OpenStack Optimize service is not supported in multi-RHEL (Red Hat Enterprise Linux) mode. Running the Optimize service in multi-RHEL mode leads to service disruption, specifically on Compute nodes that are running on RHEL 9.2 and RHEL 9.4.

Jira:OSPRH-22853

RHOSO administrators can evaluate the chargeback and rating capabilities of RHOSO clouds by enabling the Rating service (cloudkitty) in the Telemetry Operator.

The Rating service collects data from the RHOSO Telemetry service to generate cloud resource usage through rating reports. These reports can be consumed by external financial operations or billing systems. The Rating service does not provide a billing interface.

Jira:RHOSSTRAT-623

The problem occurs because a single RabbitMQ node is specifically selected in the scrape configuration, rather than the entire cluster. This leads to an incomplete RabbitMQ cluster view for clusters with multiple nodes, providing limited user insight. There is no workaround.

Jira:OSPRH-21020

If there are many similar child providers defined under the same root provider, the allocation candidate generation algorithm in the Placement service scales poorly with the default configuration of placement.

For example, if a Compute node has 8 or more child resource providers, each providing one resource, and an instance requests 8 or more such resources each in independent request groups, then without further optimization enabled, the GET allocation_candidates query takes too long to calculate and the scheduling of the instance will fail.

In this situation, make the following configuration changes in the OpenStackControlPlane CR:

spec:
placement:
    template:
      customServiceConfig: |
         [workarounds]
         optimize_for_wide_provider_trees = True
         [placement]
         max_allocation_candidates = 1000
         allocation_candidates_generation_strategy = breadth-first

Jira:OSPRH-20355

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

The image properties weigher does not take the os_version or os_admin_user properties into account when calculating the raw weights when these properties are included in the configuration.

Jira:OSPRH-21740

When a data plane node is rebooted, the edpm_bootstrap service no longer fails with the error The conditional check 'not boot_file_entry_present' failed.

Jira:OSPRH-21709

Red Hat OpenStack Services on Openshift (RHOSO) uses metal3 for provisioning unprovisioned dataplane nodes. An error state occurs when you must replace a node where the bootMacAddress cannot be updated. The result is that the node is stuck in a state where it must be completely removed from the deployment and provisioned as if it is a new node. If the automatedCleaningMode attribute is set automatedCleaningMode: disabled, this error state does not occur.

Workaround: When provisioning unprovisioned dataplane nodes, ensure the automatedCleaningMode attribute is set to automatedCleaningMode:disabled.

Jira:OSPRH-20302

Before this update, bond interfaces configured in the OpenStackControlPlane custom resource (CR) for OVN gateways failed. The ovn-operator would throw an error similar to the following:

…
Path:"" ERRORED: error configuring pod [openstack/ovn-controller-ovs-5rjnm] networking: [openstack/ovn-controller-ovs-5rjnm/68204fb3-394d-4990-80d3-fc2e388c2ee3:datacentre]: error adding container to network "datacentre": failed to move link invalid argument
': StdinData:
…

With this update, the problem has been resolved, and the ovn-operator correctly creates bond interfaces on the ovn-controller and ovn-controller-ovs pods.

Jira:OSPRH-18544

When deploying RHOSO with both the neutron-fwaas driver and log API plugins, end users might experience log creation failure. To work around this issue, do not use both the neutron-fwaas driver and log API plugins in the same neutron deployment.

Jira:OSPRH-21926

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

When you upload an image to the Image service (glance) that is larger than the configured image size limit (image_size_total), the upload succeeds because the Image service does not verify the image size before upload. When the image is uploaded and stored, the Image service determines the image size, which might exceed the quota. However, the Image service rejects any subsequent uploads because the quota is exceeded.

Jira:OSPRH-20618

In RHOSO 18, the cinder-manage quota check and cinder-manage quota sync commands fail when no project-id argument is specified, preventing accurate management of quota usage in the Block Storage service (cinder).

Workaround: There is currently no workaround for this issue.

Jira:OSPRH-19057

Currently, if you attempt to migrate a volume when a volume type has a volume_backend_name parameter value that does not match the destination pool volume_backend_name parameter value, an error is raised.

Workaround: Configure all volume types and cinder pools that will participate in volume migrations to a common value for the volume_backend_name.

Jira:OSPRH-20763

In RHOSO 18, the Optimize service (watcher) Engine does not automatically revert failed actions when an Action Plan fails, when configured to do so by enabling the watcher_applier.rollback_when_actionplan_failed configuration option.

Workaround: Manually revert each failed action in the Action Plan. To avoid the rollback, you can diagnose and fix the root cause of the failure and then run the Audit again to propose a new solution.

Jira:OSPRH-19735

Previously, this feature was available as Technology Preview. With this release, you can migrate Compute hosts with /var/lib/nova/instances on NFS as part of the adoption of a RHOSP 17.1 deployment. 

Jira:OSPRH-9175

Previously, a bug fix was made to OVS that changed the application of the kernel’s default QOS policy to OVS ports. This fix was applied to 17.1 but not to 18.0. As a result, a regression in the network configuration for OVS interfaces negatively impacted network performance of Openstack instances when using kernel OVS. With this update, the os-vif OVS plugin has been enhanced to improve network performance on OVS interfaces by using the linux-noop QOS policy by default. This can still be overridden by neutron QOS policies. To apply the update, restart or move the instance to recreate the port with a hard reboot, perform a detach followed by an attach operation, or perform a live migrate operation.

Jira:OSPRH-18532

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

If there are many similar child providers defined under the same root provider, the allocation candidate generation algorithm in the Placement service scales poorly with the default configuration of placement.

For example, if a Compute node has 8 or more child resource providers, each providing one resource, and an instance requests 8 or more such resources each in independent request groups, then without further optimization enabled, the GET allocation_candidates query takes too long to calculate and the scheduling of the instance will fail.

In this situation, make the following configuration changes in the OpenStackControlPlane CR:

spec:
placement:
    template:
      customServiceConfig: |
        [workarounds]
        optimize_for_wide_provider_trees = True
        [placement]
       max_allocation_candidates = 1000
        allocation_candidates_generation_strategy = breadth-first

Jira:OSPRH-20355

The image properties weigher does not take the os_version or os_admin_user properties into account when calculating the raw weights when these properties are included in the configuration.

Jira:OSPRH-21740

In RHOSO 18.0.14, the DNS service (designate) is now fully supported. For more information, see Configuring DNS as a service.

Jira:RHOSSTRAT-109

In RHOSO 18.0.14, the Load-balancing service (octavia) flow resumption, which automatically reassigns the flow to an alternate controller if the original controller shuts down unexpectedly. For more information, see Avoiding taskflow interruptions by using flow resumption.

Jira:RHOSSTRAT-554

In RHOSO 18.0.14, creating load balancers in availability zones (AZs) are now fully supported. For more information, see Creating availability zones for load balancing of network traffic at the edge.

Jira:RHOSSTRAT-577

In RHOSO 18.0.14, the OVN provider driver for the Load-balancing service is no longer a Technology Preview and is now fully supported. For more information, see Load-balancing service provider drivers.

Jira:RHOSSTRAT-775

With this update, the Prometheus OVS/OVN exporter collects additional metrics related to OCP gateways, ovn-controller, and ovs-vswitchd. In addition, OVS/OVN metrics collection is now available on control plane pods. Previously, collection was only available on data plane nodes.

For more information, see Network observability.

Jira:RHOSSTRAT-847

With this update, the Prometheus OVS/OVN exporter collects additional metrics related to northd and RAFT. In addition, OVS/OVN metrics collection is now available on control plane pods. Previously, collection was only available on data plane nodes. For more information, see Network observability

Jira:RHOSSTRAT-848

In RHOSO feature release 4, you can configure your dynamic routing environment using IPv6 networks. For more information, see Preparing RHOCP for BGP networks on RHOSO.

Jira:RHOSSTRAT-972

Before this update, disabled load-balancer members remained in an ERROR state even after being re-enabled, causing incorrect load balancer status reporting and potential traffic distribution issues. This problem was caused by the health monitor incorrectly reporting the disabled member status as ERROR instead of OFFLINE. This incorrect status prevented the disabled member from transitioning back to ONLINE when it was re-enabled. With this update, the health monitor correctly sets the disabled member status to OFFLINE and the problem has been resolved. Disabled members are now correctly marked as OFFLINE and the members automatically transition back to ONLINE when they are re-enabled.

Jira:OSPRH-20743

In this release, you can test a technology preview of TAPaaS.

TAPaaS provides a Openstack integrated framework for scalable port mirroring in a multi-tenant shared environment maintaining the tenant isolation boundaries in Openstack deployments. TAPaaS is a Neutron extension that enables on-demand traffic mirroring for tenant or administrator purposes. It allows users to create TAP services that mirror traffic from one or more Neutron ports and redirect it to a TAP destination—often a virtual Network Packet Broker (NPB), intrusion detection system (IDS), or traffic analyzer instance.

Jira:RHOSSTRAT-39

In RHOSO 18.0.14 (Feature Release 4), you can test a technology preview of Firewall-as-a-Service (FWaaS). Do not use technology preview features in production environments.

As more OpenStack-based clouds are adopted for multi-tenant applications, security remains a top priority. Network-level isolation and traffic control become critical, especially in public or hybrid cloud environments.

Although security groups provide sufficient capability to specify security policy at a VM instance level or VM port level, it does not have support to specify policy at a network or router port level.

FWaaS project provides this additional capability to specify the security policies at the router port level and enables specifying multiple policy rules within the same policy group and also supports application of L3 or L2 policy at the router port level.

FWaaS also provides support for NGFW 3rd party plugins for integration with NGFW vendor solutions enabling firewall capabilities beyond the ACL level. Features and capabilities such as DPI, Malware protection, IPS and IDP.

To enable the FWaaS service plugin, add firewall_v2 to service_plugins in your control plane Custom Resource (CR) file as shown in the following example. The example includes other example services for context. These are not required for enabling FWaaS.

To configure the technology preview of FWaaS, add the following settings in your control plane CR:

customServiceConfig: |
  [DEFAULT]
  service_plugins = qos,ovn-router,trunk,segments,port_forwarding,log,firewall_v2

  [service_providers]
  service_provider = FIREWALL_V2:fwaas_db:neutron_fwaas.services.firewall.service_drivers.ovn.firewall_l3_driver.OVNFwaasDriver:default

For FWaaS usage examples, see "Configure Firewall-as-a-Service v2" in Firewall-as-a-Service (FWaaS) v3 scenario [1].

[1] https://docs.openstack.org/neutron/latest/admin/fwaas-v2-scenario.html

Jira:RHOSSTRAT-499

With this technology preview, you can upgrade in-place an OpenStack deployment from RHOSP 17.1 to RHOSO 18 by deploying a parallel control plane based on RHOSO 18 and then pointing the compute nodes to the new control plane.

Jira:RHOSSTRAT-902

A NIC on a data plane node can be used for bare-metal provisioning and other initial configuration tasks. You can then use os-net-config to reconfigure the NIC for operational use in your deployment. In these cases, obsolete remnants of the initial configuration might cause IP address conflicts. To avoid such conflicts, you can use remove_config to clean up the obsolete configuration files from the initial configuration. For more information, see Cleaning up obsolete host network configurations.

Jira:RHOSSTRAT-660

In previous RHOSO releases, Red Hat did not support NMstate as the os-net-config provider. It is now supported and the default configuration sets the os-net-config provider to nmstate.

The parameter is edpm_network_config_nmstate. The default value is true. If a specific limitation of the nmstate provider requires you to use the ifcfg provider, change edpm_network_config_nmstate to false.

For more information, see "The nmstate provider for os-net-config" in the guide Planning your deployment

Jira:OSPRH-11309

This enhancement ensures correct version tracking and validation during minor updates by preventing the side effects and inconsistencies that result from custom container images not being updated when the target version is updated.

With this update, when a minor update is initiated by setting the targetVersion, the performance of the minor update is halted if the customImages version for the associated custom container images is not also updated. Users have the option to force the update if necessary.

Jira:OSPRH-19183

This enhancement updates the RabbitMQ service Operator, rabbitmq-cluster-operator, to version 2.16.0. With this update, the RabbitMQ clusters are restarted. If you want to control when the RabbitMQ clusters are updated, you can pause reconciliation before performing the update, then resume reconciliation when it is safe to update the RabbitMQ cluster.

Jira:RHOSSTRAT-914

The OpenStack Operator initialization resource creates each {rhocp_long} service Operator with default CPU and memory resource limits, and default tolerations. This enhancement adds the ability to customize the configuration of the resource limits and tolerations of each {rhocp_long} service Operator.

Jira:RHOSSTRAT-974

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

Starting with RHOSO 18.0.14 (Feature Release 4), you can configure the cache maintained by the memcached service to require authentication to increase the security of your cloud by restricting access to the cached data of your cloud. For more information, see Configuring authentication for the memcached service in Customizing the Red Hat OpenStack Services on OpenShift deployment.

Jira:RHOSSTRAT-288

Starting with RHOSO 18.0.14 (Feature Release 4), you can adopt Red Hat OpenStack Platform (RHOSP) 17.1 environments with Instance HA enabled to RHOSO 18.0. For more information about adopting Instance HA environments, see Preparing an Instance HA deployment for adoption and link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/adopting_a_red_hat_openstack_platform_17.1_deployment/adopting-data-plane_adopt-control-plane#enabling-high-availability-for-instances_data-plane [Enabling the high availability for Compute instances service] in Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:RHOSSTRAT-654

Starting with RHOSO 18.0.14 (Feature Release 4), RabbitMQ supports the use of the Quorum queues for new RHOSO deployments. A Quorum queue is a durable, replicated queue based on the Raft consensus algorithm, providing increased data safety and high availability. For more information, see step 5 of link: Creating the control plane in the Deploying Red Hat OpenStack Services on OpenShift guide.

Jira:RHOSSTRAT-959

Starting with RHOSO 18.0.14 (Feature Release 4), you can configure RHOSO to allow users to log in to the OpenStack Dashboard by using single sign-on (SSO) and select from one of several external Identity Providers (IdPs). For more information, see Configuring multi-realm federated authentication in RHOSO in Configuring security services.

Jira:RHOSSTRAT-613

With this update, the Image service (glance) now supports the customization of HTTPd configuration files. You can use the extraMounts parameter to include and load a custom httpd.conf file.

Jira:OSPRH-20033

With this update, the Shared File Systems service (manila) now supports the customization of HTTPd configuration files. You can use the extraMounts parameter to include and load a custom httpd.conf file.

Jira:OSPRH-20335

With this update, the Image service (glance) supports per-tenant quotas for improved resource management in private clouds.

Jira:RHOSSTRAT-1004

Adopting the Shared File Systems service (manila) with CephFS through NFS is now generally available. Previously, these adoption instructions were provided as a Technology Preview.

This enhancement allows you to migrate your existing Red Hat OpenStack Platform 17.1 deployment that uses CephFS through NFS as a back end for the Shared File Systems Service to RHOSO 18.0 with full support.

The adoption process includes:

Starting with RHOSO 18.0.14 (Feature Release 4), the procedure to adopt RHOSO 18.0 is fully supported for Red Hat OpenStack Platform 17.1 environments that use iSCSI as a back end for the Block Storage service (cinder). For more information, see Adopting the Block Storage service in Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:RHOSSTRAT-507

With this update, the Image service (glance) adds Cache API support. The Image service Cache API provides centralized management of cache nodes, eliminating the requirement for individual SSH connections. Key functionalities include listing cached images of a specific node, queuing images for caching, and deleting cached images or images queued for caching. With this update, administrators can call the API and integrate API calls into workflows and automated tasks.

Jira:RHOSSTRAT-606

Starting with RHOSO 18.0.14 (Feature Release 4), RHOSO 18.0 adoption is fully supported for Red Hat OpenStack Platform 17.1 environments that use Block Storage service (cinder) as a back end for the Image service (glance). For more information, see Adopting the Image service that is deployed with a Block Storage service back end in Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:RHOSSTRAT-670

With this update, you can deploy the Object Storage service (swift) on external data plane nodes, improving scalability and performance for large storage clusters. By enabling DNS forwarding and creating an OpenStackDataPlaneNodeSet CR with specified properties, including disks for storage, you can customize the service configuration through additional ConfigMap or Secret CRs in the OpenStackDataPlaneService CR.

Jira:RHOSSTRAT-684

The Shared File Systems service (manila) now supports transferring shares across projects. To ensure security and non-repudiation, a one-time transfer secret key is generated when you initiate a transfer. The key must be conveyed out-of-band so that a user in the recipient project can complete the transfer.

Jira:RHOSSTRAT-784

The Shared File Systems service (manila) now includes integration with Dell PowerScale storage systems (formerly Dell Isilon). The driver supports provisioning and managing the lifecycle of NFS and CIFS shared file systems, controlling client access to them, resizing them, creating snapshots, and cloning these snapshots into new shared file systems.

Jira:RHOSSTRAT-803

With this update, you can enable notifications in the Block Storage service (cinder) and Shared File System service (manila) by using the notificationsBusInstance parameter, allowing integration with either the existing RabbitMQ instance or a dedicated RabbitMQ instance.

Jira:RHOSSTRAT-876

Before this update, the creation of snapshots for Block Storage service (cinder) volumes did not succeed in ONTAP FlexGroup pools. With this update, the creation of volume snapshots succeeds, ensuring data backup for end users.

Jira:OSPRH-19954

Before this update, when a PowerFlex volume in the image volume cache reached its snapshot limit, the Block Storage service (cinder) replaced the cache entry. However, the volume itself was not deleted, resulting in unusable volumes that consumed quota. Now, when a PowerFlex volume in the image volume cache reaches its snapshot limit, the Block Storage service replaces the cache entry and deletes the PowerFlex volume for the original cache entry.

Jira:OSPRH-20193

Before this update, NetApp ONTAP storage systems on version 9.13.1 or later rejected clone deletion requests for FlexVol snapshots and FlexClones if they were still processing. With this update, the NetApp ONTAP driver in the Shared File Systems service (manila) manages clone splitting operations before share or snapshot deletion, preventing deletion failures. Users can now delete Shared File Systems service snapshots and shares created from snapshots any time after creation without encountering clone deletion failures.

Jira:OSPRH-20328

In RHOSO 18, the cinder-manage quota check and cinder-manage quota sync commands fail when no project-id argument is specified, preventing accurate management of quota usage in the Block Storage service (cinder).

Workaround: There is currently no workaround for this issue.

Jira:OSPRH-19057

When you upload an image to the Image service (glance) that is larger than the configured image size limit (image_size_total), the upload succeeds because the Image service does not verify the image size before upload. When the image is uploaded and stored, the Image service determines the image size, which might exceed the quota. However, the Image service rejects any subsequent uploads because the quota is exceeded.

Jira:OSPRH-20618

With this update, you can customize the httpd timeout value of your Dashboard horizon-operator by using extraMounts to load a httpd.conf file. For more information, see link: https://github.com/openstack-k8s-operators/horizon-operator/blob/main/config/samples/httpd-overrides/README.md

Jira:OSPRH-10961

With this update, the direct upload method is the default upload method in the Dashboard service (horizon). The direct upload method requires Cross-Origin Resource Sharing (CORS) to be enabled in the Image service (glance), and CORS is now enabled by default in the glance-operator.

As a result, you can use the web UI in the Dashboard service to upload images that are greater than 1 GiB in size. The direct upload method sends the image directly from the web browser to the Image service instead of storing the image in the Dashboard service first and then sending it to the Image service.

Jira:RHOSSTRAT-917

Before this update, the Optimize service (watcher) was provided as a technical preview that was installed with its own Operator. With this update, the Optimize service is now integrated into the OpenStack Operator and is fully supported.

If you have installed the Optimize service as a technical preview, you must remove the Optimize service Operator and any custom resource of kind `Watcher` before updating your RHOSO deployment to 18.0.14 or later.

Jira:OSPRH-14852

With this update, you can now enable the Optimize service (watcher) to receive notification updates from other OpenStack services, which improves Optimize service accuracy.

Jira:OSPRH-18674

With this update, you can now set the start and end times when creating CONTINUOUS audits in the OpenStack Dashboard (horizon).

Jira:OSPRH-19133

With this update, you can now include parameters as JSON values when creating an Audit in the Openstack Dashboard.

Jira:OSPRH-20000

With this update the OpenStack Dashboard now limits visible strategies to those applicable to the selected goal.

Jira:OSPRH-20148

Before this update, legacy code in the Optimize service (watcher) related to the volume move operation could result in two instances having access to the same host block device, which could lead to corruption or incorrect data access between tenants after a volume was migrated.

This update resolves the data corruption and data access issues by removing legacy code and delegating volume migrations to the Block storage service (cinder).

Jira:OSPRH-19167

In RHOSO 18, the Optimize service (watcher) Engine does not automatically revert failed actions when an Action Plan fails, when configured to do so by enabling the watcher_applier.rollback_when_actionplan_failed configuration option.

Workaround: Manually revert each failed action in the Action Plan. To avoid the rollback, you can diagnose and fix the root cause of the failure and then run the Audit again to propose a new solution.

Jira:OSPRH-19735

Currently, if you attempt to migrate a volume when a volume type has a volume_backend_name parameter value that does not match the destination pool volume_backend_name parameter value, an error is raised.

Workaround: Configure all volume types and cinder pools that will participate in volume migrations to a common value for the volume_backend_name.

Jira:OSPRH-20763

In RHOSO 18.0.14 (Feature Release 4) and RHOSP 17.1, you can now migrate workloads from VMware to OpenStack using the VMware Migration Toolkit.

Jira:RHOSSTRAT-89

Red Hat OpenStack Services on Openshift (RHOSO) uses metal3 for provisioning unprovisioned dataplane nodes. An error state occurs when you must replace a node where the bootMacAddress cannot be updated. The result is that the node is stuck in a state where it must be completely removed from the deployment and provisioned as if it is a new node. If the automatedCleaningMode attribute is set automatedCleaningMode: disabled, this error state does not occur.

Workaround: When provisioning unprovisioned dataplane nodes, ensure the automatedCleaningMode attribute is set to automatedCleaningMode:disabled.

Jira:OSPRH-20302

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

An issue with Red Hat Ceph Storage prevents the use of IPv6 export locations with Shared File Systems service (manila) shares that have a CephFS-NFS back end. Workaround: Currently, there is no workaround.

Jira:OSPRH-19498

RHOSO 18.0.10 (Feature Release 3) introduced a new update workflow that splits the OpenStack-related package updates and system-related package updates. With this new feature, the data plane update service is deprecated in favor of the split update-services and update-system services. The update service will be removed in a future release. Customers should transition to using the split update feature. For more information about the split update feature, see the Red Hat Knowledgebase article Performing a minor update of OpenStack service containers and RHEL RPMs separately.

Jira:OSPRH-20354

Currently, if you attempt to migrate a volume when a volume type has a volume_backend_name parameter value that does not match the destination pool volume_backend_name parameter value, an error is raised.

Workaround: Configure all volume types and cinder pools that will participate in volume migrations to a common value for the volume_backend_name.

Jira:OSPRH-20763

In RHOSO 18, the Optimize service (watcher) Engine does not automatically revert failed actions when an Action Plan fails, when configured to do so by enabling the watcher_applier.rollback_when_actionplan_failed configuration option.

Workaround: Manually revert each failed action in the Action Plan. To avoid the rollback, you can diagnose and fix the root cause of the failure and then run the Audit again to propose a new solution.

Jira:OSPRH-19735

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

An issue with Red Hat Ceph Storage prevents the use of IPv6 export locations with Shared File Systems service (manila) shares that have a CephFS-NFS back end. Workaround: Currently, there is no workaround.

Jira:OSPRH-19498

Previously, a bug fix was made to OVS that changed the application of the kernel’s default QOS policy to OVS ports. This fix was applied to 17.1 but not to 18.0. As a result, a regression in the network configuration for OVS interfaces negatively impacted network performance of Openstack instances when using kernel OVS. With this update, the os-vif OVS plugin has been enhanced to improve network performance on OVS interfaces by using the linux-noop QOS policy by default. This can still be overridden by neutron QOS policies. To apply the update, restart or move the instance to recreate the port with a hard reboot, perform a detach followed by an attach operation, or perform a live migrate operation.

Jira:OSPRH-18532

Previously, a Compute instance with an ISO image booted via a block device instead of CD-ROM. This prevented the RHEL Kickstart installation from initiating from the CD-ROM. With this bug fix, Compute boots the instance from the ISO image correctly and via CD-ROM.

Jira:OSPRH-17569

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

This update fixes an issue where upgrades from OpenStack Operator version 1.0.6 or earlier sometimes failed when OpenShift Lifecycle Manager (OLM) Operator resources contained data with no namespace field defined.

With this update, the OpenStack Operator checks that the namespace field is implemented for Operator references in the OpenStack controller and the OpenStack Service Operators upgrade is not affected.

Jira:OSPRH-17456

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

Before this update, you had to use the image import workflow to upload multipart images if you had an S3 back end for the Image service (glance). With this update, you can set s3_store_large_object_size to 0 to force multipart upload when you create an image in the S3 back end from a Block Storage service (cinder) volume.

Jira:OSPRH-11018

An issue with Red Hat Ceph Storage prevents the use of IPv6 export locations with Shared File Systems service (manila) shares that have a CephFS-NFS back end. Workaround: Currently, there is no workaround.

Jira:OSPRH-19498

Volume migration operations that are a part of the zone migration strategy are provided as a technology preview only, and should not be used in production.

Jira:OSPRH-17639

This enhancement implements a new exporter that enables observability of the MariaDB databases that run within RHOSO.

Jira:RHOSSTRAT-882

Telemetry data for Compute nodes is now collected directly from Prometheus rather than transiting the internal message bus, enabling storage of Compute node telemetry in the telemetry storage system.

[NOTE] You cannot collect Compute node metrics from Prometheus in an IPv6 environment.

Jira:RHOSSTRAT-905

This update fixes an issue where DNS search domains (dns_search_domains) shorter than 8 characters that appeared alphabetically before the control plane DNS domain caused disruption in the collection of telemetry data.

Jira:OSPRH-16162

This update adds support for configuring a dedicated notifications message bus in the nova-operator. By setting the notificationsBusInstance in the Nova custom resource (CR), operators can specify an external RabbitMQ for emitting versioned and unversioned notifications.

The [notification] and [oslo_messaging_notifications] sections are rendered in nova.conf.

When novaEnabledNotification is set and a transport_url is provided via an OpenShift secret, nova-compute emits structured notifications to external systems, improving integration and observability in RHOSO environments.

To enable Nova notifications in RHOSO, you update the OpenStackControlPlane CR to add a new RabbitMQ instance and reference it in the Nova CR by using notificationsBusInstance. The nova-operator configures control plane services automatically.

For data plane updates, redeploy the data plane nodes.

Jira:OSPRH-16489

The cloud operator can now adopt an existing 17.1 multi-cell nova deployment with a common network from TripleO management to the new installer for RHOSO.

Jira:OSPRH-6548

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including those used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

Before this update, cross-controller packet loss could impact request handling by the python-networking-baremetal agent and prevent physical network mapping updates from occurring in the Networking service (neutron) for bare-metal nodes. With this update, there is additional logging and error handling so that the python-networking-baremetal provided service exits and the container can automatically restart if packet loss occurs. Physical network mappings for bare-metal nodes continue to to be updated if network interruptions for Controller nodes occur.

Jira:OSPRH-10799

This update solves an issue in the Bare Metal Provisioning service (ironic) that caused the deployment process to loop and time out because of interruptions in connectivity while the deployment agent was starting. The issue occurred because only one attempt was made to evaluate if a RAM drive was recently booted. When this issue occurred, the bare metal nodes would fail to clean, deploy, or perform other workflow actions.

Jira:OSPRH-15883

Adoption of RHOSP 17.1 environments that use combined Controller/Networker nodes are verified to work as documented in Adopting a Red Hat OpenStack Platform 17.1 deployment.

Jira:OSPRH-10714

Before this update, OpenStack did not fragment north-south packets as expected when the external maximum transmission unit (MTU) was less than the internal MTU, which resulted in packets being dropped silently. With this update, fragmentation happens as expected, and packets are not dropped silently.

Jira:OSPRH-12695

Before this update, disabling Bidirectional Forwarding Detection (BFD) in Free Range Routing (FRR) on RHEL 9.4 could cause traffic disruptions during error recovery.

With this release, you no longer need to disable BFD for BGP peers. Operating with BFD for BGP peers enhances BGP time recovery and minimizes traffic disruption.

Jira:OSPRH-15728

With this technology preview, you can test the management of DNS records, names, and zones using the DNS service (designate). For more information, see Configuring DNS as a service.

Jira:RHOSSTRAT-441

With this technology preview, you can test creating load balancers in availability zones (AZs) to increase traffic throughput, reduce latency, and enhance security. For more information, see Creating availability zones for load balancing of network traffic at the edge.

Jira:RHOSSTRAT-528

Load-balancing service (octavia) resources are created by default within a project (tenant) service. RHOSO 18.0.10 (Feature Release 3) introduces a technology preview of a new TenantName parameter for the Octavia Operator, which restricts the use of the resource to a specific project. RHOSO administrators can also change the domain of the project.

Jira:RHOSSTRAT-614

Since RHOSO 18.0.10 (Feature Release 3), the OVN BGP Agent ovn-bgp-agent is deprecated. ovn-bgp-agent is the BGP integration component in RHOSO. An alternative BGP integration mechanism is scheduled for a future release. Until then, Red Hat will provide only bug fixes and support for this feature.

Jira:OSPRH-17130

RHOSO 18.0.6 (Feature Release 2) introduced a technology preview of TCP segmentation offload (TSO) for RHOSO environments with OVS-DPDK.

As of RHOSO 18.0.10 (Feature Release 3), TCP segmentation offload (TSO) for RHOSO environments with OVS-DPDK is a general availability feature.

Jira:OSPRH-3885

Previously, when the physical function (PF) was attached to the instance, if os-net-config was re-run, os-net-config could not find the SR-IOV PF in the host, and the adoption failed. With this release, the adoption does not fail.

Jira:OSPRH-12024

Before this update, the NetworkManager-dispatcher service was blocked by SELinux permission denial, causing the service to fail when SELinux was enforced. With this release, NetworkManager has been updated to allow running the`NetworkManager-dispatcher` service with SELinux in enforcing mode. As a result, the NetworkManager-dispatcher service now runs with SELinux in enforcing mode, eliminating the failures.

Jira:OSPRH-13544

Before this update, when pre-provisioning Compute nodes for communicating with the control plane over VLANs, theNetworkManager CLI (nmcli) connection was not always created with the proper interface name. This caused deployment failures.

With this release, the issue with the nmstate provider for handling vlan interfaces in pre-provisioned nodes has been resolved. As a result, data plane deployments using the nmstate provider succeeds.

Jira:OSPRH-16526

The flag edpm_network_config_nonconfigured_cleanup: true was introduced as default in Feature Release 2 and caused some new deployments to fail.

With this update, appropriate use of the flag edpm_network_config_nonconfigured_cleanup: true no longer causes deployment failures.

You can now set edpm_network_config_nonconfigured_cleanup: true when you do the following configurations:

Previously, in environments using the os-net-config nmstate provider, QoS bandwidth limit rules were not properly applied to the physical NIC attached to the br-ex bridge.

With this update, the QoS bandwidth limit rules are applied.

Jira:OSPRH-17551

This update fixes an issue in environments with the nmstate provider where network updates failed on Compute nodes that hosted active instances with patch ports present in br-ex.

Jira:OSPRH-17622

This feature enables you to deploy multiple RHOSO environments on a single RHOCP cluster by using namespace (project) isolation for development, staging and testing environments.

For more information, see Deploying multiple RHOSO environments on a single RHOCP cluster

Jira:RHOSSTRAT-612

During a minor update, the control plane services are updated concurrently. This enhancement isolates the galera, rabbitmq, memcached, and keystone services to perform their updates consecutively, in order, within the minor control plane services update phase.

Jira:RHOSSTRAT-871

The Installing the OpenStack Operator procedure has been updated to include changing the default automatic Operator update approvals to manual approvals. Using manual update approval enables RHOSO administrators to schedule RHOSO Operator updates.

Jira:RHOSSTRAT-890

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine instance created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

This update fixes an issue where upgrades from OpenStack Operator version 1.0.6 or earlier sometimes failed when OpenShift Lifecycle Manager (OLM) Operator resources contain data with no namespace field defined.

With this update, the OpenStack Operator checks that the namespace field is implemented for Operator references in the OpenStack controller and the OpenStack Service Operators upgrade is not affected.

Jira:OSPRH-17456

Before this update, the BGPConfiguration parameter spec.frrNodeConfigurationSelector.nodename had an inconsistency in its JSON tag where the NodeName string json:"frrConfigurationNamespace,omitempty was incorrect because frrConfigurationNamespace is a node name. With this update, the NodeName string in the JSON tag is correctly set as json:"nodeName,omitempty". You can now configure the frrNodeConfigurationSelector by using the following spec:

    frrNodeConfigurationSelector:
    - nodeName: nodeA
      nodeSelector:
        matchLabels:
          foo: bar

During an update to the fixed version, any node names that you previously specified by using the frrConfigurationNamespace JSON tag are removed and you must use the correct nodeName JSON tag to reconfigure your node names.

Jira:OSPRH-16550

With this update, the S3 driver for the Image service has a new s3_store_cacert option that allows users to specify the path to a Certificate Authority (CA) bundle to use.

Jira:OSPRH-11189

Before this update, NFS was not supported when integrating with Red Hat Ceph Storage 8. With this update, NFS is now supported with Red Hat Ceph Storage 8 integrations.

Jira:OSPRH-14788

With this update, cloud administrators can use either vast_mgmt_user and vast_mgmt_password or vast_api_token when configuring authentication in the Shared File Systems service for their VAST Data storage systems. API-based authentication is useful in RHOSO deployments if cloud administrators need an alternative to passwords when specifying VAST Data API users.

Jira:OSPRH-16085

With this update, there is improved Fibre Channel performance when detaching a volume because there is no longer a requirement to call the lsscsi command.

Jira:OSPRH-16924

RHOSO 18.0.10 (Feature Release 3) supports the integration of third-party storage appliances within distributed zone environments. The NFS and Fiber Channel protocols in distributed zone environments are provided as a technology preview and are not yet recommended for production use.

Jira:RHOSSTRAT-259

With this update, you can enable notifications in the Image service by using the notificationBusInstance parameter, allowing integration with either the existing RabbitMQ instance or a dedicated one.

Jira:RHOSSTRAT-682

With this update, you can check a CephFS file name when mounting a native CephFS share by viewing the __mount_options metadata of the share in the output of the following command:

$ openstack share show <share_id>

Jira:RHOSSTRAT-685

Before this update, Fibre Channel volume attachments failed intermittently with a NoFibreChannelVolumeDeviceFound error due to partial scanning of devices. With this update, a broader scan results in better discovery of devices and successful attach operations.

Jira:OSPRH-16737

With this update, you can test two new options to customize deployments of the Object Storage service by using externally-managed rings. With this technology preview, you can now disable automatic ring management and spread large rings over multiple configmaps.

Jira:RHOSSTRAT-789

If you upload multipart images with an S3 back end, you must use the import workflow.

Jira:OSPRH-11018

The Red Hat Ceph Storage Object Gateway (RGW) is currently not supported when integrating with Red Hat Ceph Storage 8.

Workaround: There is no current workaround.

Jira:OSPRH-14789

RHOSO 18.0.10 (Feature Release 3) introduces a feature to separate the update process for RHOSO EDPM nodes into two distinct phases:

Before this update, the implementation of the Zone migration strategy was affected by the dst_node parameter. Now the implementation is in line with API schema and the dst_node parameter is optional. If you do not specify a value for dst_node, the Nova scheduler selects an appropriate host automatically.

Jira:OSPRH-17179

This update fixes an issue where RHOSO Watcher did not correctly report the state of Action Plans after all Actions finished, for example reporting SUCCESS if some Actions actually finished with a state of FAILED.

Jira:OSPRH-17257

RHOSO 18.0.10 (Feature Release 3) introduces support for three new supported strategies in the Optimize service: host maintenance, zone migration for instances, and workload balance. For more information about supported strategies to achieve resource optimization goals, see Sample Optimize service workflows in Optimizing infrastructure resource utilization.

Jira:RHOSSTRAT-237

Volume migration operations that are a part of the zone migration strategy are provided as a technology preview only, and should not be used in production.

Jira:OSPRH-17639

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including ones used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

Before this update, the redhat service was removed temporarily from the default list of data plane services, and users had to manually add the redhat service to the list of services in the OpenStackDataPlaneNodeSet CR. With this update, the redhat service is restored to the default list of data plane services.

Jira:OSPRH-15644

Any VLAN or flat network port with egress QoS policy rules (maximum and/or minimum bandwidth) stores this information in the Logical_Switch_Port. options dictionary. Before this update, any update on this port, from a port name change to a live migration, deleted this QoS information. With this update, the QoS information persists through port updates.

Jira:OSPRH-15457

RHOSO does not fragment north-south packets as expected when the external MTU is greater than the internal MTU. Instead, the ingress packets are dropped with no notification.

Also, fragmentation does not work on east/west traffic between tenant networks.

Until these issues are resolved, ensure that the external MTU settings are less than or equal to internal MTU settings, and that all MTU settings on east/west paths are equal.

Workaround:

Until these issues are resolved, perform the following steps to ensure that the external MTU settings are less than or equal to internal MTU settings, and that all MTU settings on east/west paths are equal.

For example, suppose that the external network datacentre MTU is 1500.

Before this update, when pre-provisioning Compute nodes for communicating with the control plane over VLANs, theNetworkManager CLI (nmcli) connection was not always created with the proper interface name. This caused deployment failures.

With this release, the issue with the nmstate provider for handling vlan interfaces in pre-provisioned nodes has been resolved. As a result, data plane deployments using the nmstate provider succeeds.

Jira:OSPRH-16526

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine (VM) created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

This enhancement adds the TAGGED_AGGREGATES parameter to the RHOSO high availability for Compute instances (Instance HA) service. By default, this parameter is set to true, so that the Instance HA service checks for tagged host aggregates. If you set this parameter to false then the Instance HA service does not check for tagged host aggregates and therefore will evacuate all the eligible Compute nodes.

Jira:OSPRH-16342

If you upload multipart images with an S3 back end, you must use the import workflow.

Jira:OSPRH-11018

NFS is currently not supported when integrating with Red Hat Ceph Storage 8.

Workaround: There is no current workaround.

Jira:OSPRH-14788

The Red Hat Ceph Storage Object Gateway (RGW) is currently not supported when integrating with Red Hat Ceph Storage 8.

Workaround: There is no current workaround.

Jira:OSPRH-14789

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including ones used by instances. If the cpu_state strategy is used, the CPUs of those instances become unpinned.

Jira:OSPRH-10772

Before this update, iptables default tables were added to nftables to ensure backwards compatibility. However, there was a default ALLOW INPUT rule instead of a default DROP rule, and nftables were not reloaded at the end of the deployment. With this update, the correct rules are applied to ensure that nftables are reloaded at the end of the deployment.

Jira:OSPRH-15473

The redhat service has been removed temporarily from the default list of data plane services. As a result, when you attach subscriptions or repositories to Compute nodes and use the documented rhc_* parameters when creating the data plane secrets, the nodes are not registered and the data plane deployment fails.

Workaround: Override the services list in your OpenStackDataPlaneNodeSet CR, and ensure that you add the redhat service as the first service in the list. You can copy the default list shown in Data plane services in Customizing the Red Hat OpenStack Services on OpenShift deployment.

Jira:OSPRH-15644

Before this update, pre-built whole disk images did not include the device-mapper-multipath package, which prevented the paired boot ramdisk from supporting multi-path block storage. This caused bare-metal nodes with multi-path block storage to fail to boot after deployment and instead be stuck in an emergency shell. With this update, pre-built whole disk images now include the device-mapper-multipath package and deployed bare-metal nodes no longer enter an emergency shell after being deployed.

Jira:OSPRH-15887

Before this update, no logs were available for the Free Range Routing (FRR) service, which is deployed on the data plane nodes when RHOSO is configured to use Dynamic Routing with BGP. With this update, these logs are available.

Jira:OSPRH-10204

Before this update, there were legacy tripleo Networking service (neutron) services after the edpm_tripleo_cleanup task, which needed to be removed manually. These services were stopped after adoption, so the RHOSO services were not affected. With this update, all tripleo Networking services are removed after adoption on data plane nodes.

Jira:OSPRH-11323

RHOSO does not fragment north-south packets as expected when the external MTU is greater than the internal MTU. Instead, the ingress packets are dropped with no notification.

Also, fragmentation does not work on east/west traffic between tenant networks.

Until these issues are resolved, ensure that the external MTU settings are less than or equal to internal MTU settings, and that all MTU settings on east/west paths are equal.

Workaround:

Until these issues are resolved, perform the following steps to ensure that the external MTU settings are less than or equal to internal MTU settings, and that all MTU settings on east/west paths are equal.

For example, suppose that the external network datacentre MTU is 1500.

Any VLAN or flat network port with egress QoS policy rules (maximum and/or minimum bandwidth) stores this information in the Logical_Switch_Port. options dictionary. Any update on this port, from a port name change to a live migration, will delete this QoS information.

Workaround: To restore the QoS information, you must remove the QoS policy for this port and set it again.

Jira:OSPRH-15457

When the physical function (PF) is attached to the instance, if os-net-config is re-run, os-net-config cannot find the SR-IOV PF in the host, and thus the deployment, update, or adoption fails.

Workaround: Before performing an adoption or network update, migrate the instances to another Compute host.

Jira:OSPRH-12024

The os-net-config configuration tool uses NetworkManager-dispatcher scripts for driver bindings. When SELinux is enabled, these scripts fail to run, and the os-net-config network deployment fails.

Workaround: There is currently no workaround.

Jira:OSPRH-13544

Before this update, when updates to service configurations failed, the failure was not being reflected in the condition status of the deployment. Instead, the Ready condition showed as "True" because the new pods created by the update were not being considered when checking the deployment readiness. With this update, any new pods created during a configuration update are now considered when assessing deployment readiness. If rolling out new pods fails, then the deployment reflects that it is stuck in Deployment in progress.

Jira:OSPRH-14472

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine (VM) created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

Before this update, the CA bundle that was generated by the RHOSO control plane was deployed on the data plane node for deployed or running services, but it did not get installed as the CA bundle on the data plane node itself. The CA bundle can include custom third-party CA files, for example, to access a satellite. With this update, the CA bundle gets installed on the data plane node.

Jira:OSPRH-14205

Before this update, if the Compute service (nova) API raised a configuration error, it returned a 500 error once, and then continued to run with a broken configuration after a reload. This issue occurred because mod_wsgi reloaded the wsgi application into the same Python interpreter when an error was raised during application initialization. With this update, the Compute service has been modified to reraise the configuration error until the application can restart cleanly. Now, if you deploy with an invalid configuration, the Compute service API CR fails the ready check and updates the Status field in the OpenShift CR to prompt you to review the log files for the configuration error.

Jira:OSPRH-9737

The Compute service (nova) power management feature is disabled by default. You can enable it with the following nova-compute configuration:

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

The default cpu_power_management_strategy cpu_state is currently unsupported. Restarting nova-compute causes all dedicated PCPUs on that host to be powered down, including ones used by instances. If the cpu_state strategy is used, those instances' CPUs will become unpinned.

Jira:OSPRH-10772

The redhat service has been removed temporarily from the default list of data plane services. As a result, when you attach subscriptions or repositories to Compute nodes and use the documented rhc_* parameters when creating the data plane secrets, the nodes are not registered and the data plane deployment fails.

Workaround: Override the services list in your OpenStackDataPlaneNodeSet CR, and ensure that you add the redhat service as the first service in the list. You can copy the default list shown in Data plane services in Customizing the Red Hat OpenStack Services on OpenShift deployment.

Jira:OSPRH-15644

Before this update, when you deployed RHOSO with Dynamic Routing with border gateway protocol (BGP), bi-directional forwarding (BFD) did not work as expected because there was no nft rule to permit BFD and BGP ports. With this update, an nft rule has been added and BFD works as expected:

  BGP
       - 179 tcp
   BFD
       - 3784 udp
       - 3785 udp
       - 4784 udp
       - 49152 udp
       - 49153 udp

Jira:OSPRH-14536

No logs are available for the FRR service, which is deployed on the data plane nodes when RHOSO is configured to use Dynamic Routing with BGP.

Workaround:

To obtain FRR logs after the OpenstackDataplaneDeployment is complete, perform the following actions on all the networker and Compute nodes that are running FRR:

After the edpm_tripleo_cleanup task, there are still legacy tripleo Networking service (neutron) services. These services are stopped after adoption, so the RHOSO services are not affected.

Workaround:

Perform the following steps to remove the legacy services manually:

RHOSO does not fragment north-south packets as expected when the external MTU is greater than the internal MTU. Instead, the ingress packets are dropped with no notification.

Also, fragmentation does not work on east/west traffic between tenant networks.

Until these issues are resolved, ensure that the external MTU settings are less than or equal to internal MTU settings, and that all MTU settings on east/west paths are equal.

Workaround:

Until these issues are resolved, perform the following steps to ensure that the external MTU settings are less than or equal to internal MTU settings, and that all MTU settings on east/west paths are equal.

For example, suppose that the external network datacentre MTU is 1500.

Any VLAN or flat network port with egress QoS policy rules (maximum and/or minimum bandwidth) stores this information in the Logical_Switch_Port. options dictionary. Any update on this port, from a port name change to a live migration, will delete this QoS information.

Workaround: To restore the QoS information, you must remove the QoS policy for this port and set it again.

Jira:OSPRH-15457

This update fixes a bug that causes minor update failures during updates from RHOSO 18.0.1 through 18.0.5 to 18.0.6 or later. The failure no longer occurs if you update from RHOSO 18.0.6 or later to any version.

Workaround: Add the telemetry service to the servicesOverride field in the openstack-edpm-update-services.yaml file before you update the `OpenStackDataplaneService`custom resource. For example:

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneDeployment
metadata:
  name: edpm-deployment-ipam-update-dataplane-services
spec:
  nodeSets:
    - openstack-edpm-ipam
  servicesOverride:
    - telemetry
    - update

Jira:OSPRH-14841

You can stop using the edpm_ovs_dpdk_lcore_list Ansible variable in RHOSO deployments. Previously, it was used in nodeset CR definition files to enable OVS DPDK in data plane deployments in NFV environments. It is no longer required or supported, and its use now causes deployment errors.

Jira:OSPRH-14642

When the physical function (PF) is attached to the instance, if os-net-config is re-run, os-net-config cannot find the SR-IOV PF in the host, and thus the deployment, update, or adoption fails.

Jira:OSPRH-12024

The os-net-config configuration tool uses NetworkManager-dispatcher scripts for driver bindings. When SELinux is enabled, these scripts fail to run, and the os-net-config network deployment fails.

Workaround: There is currently no workaround.

Jira:OSPRH-13544

Before this update, HTTP TRACE was enabled by default from the OpenStackProvisionServer CR which resulted in security scanners creating an alert. With this update, the TraceEnable parameter has been set to the value "off" by default in the httpd configuration.

Jira:OSPRH-14672

During minor updates, the RHOSO control plane temporarily becomes unavailable. API requests might fail with HTTP error codes, such as error 500. Alternatively, the API requests might succeed but the underlying life cycle operation fails. For example, a virtual machine (VM) created with the openstack server create command during the minor update never reaches the ACTIVE state. The control plane outage is temporary and automatically recovers after the minor update is finished. The control plane outage does not affect the already running workload.

Workaround: To prevent this disruption, see the Red Hat Knowledgebase article How to enable mirrored queues in Red Hat Openstack Services on OpenShift.

Jira:OSPRH-10790

The CA bundle that is generated by the RHOSO control plane gets deployed on the data plane node for deployed or running services, but it does not get installed as the CA bundle on the data plane node itself. The CA bundle can include custom third-party CA files, for example, to access a satellite. Workaround: There is currently no workaround.

Jira:OSPRH-14205

The Red Hat OpenStack Services on OpenShift (RHOSO) Optimize service (watcher) provides a flexible and scalable resource optimization service for multi-tenant RHOSO-based clouds. The Optimize service provides a framework to help you set and manage goals for infrastructure resource utilization.

The Optimize service is focused on helping users realize a wide range of infrastructure resource utilization goals toward reducing data center operating costs. It includes a metrics receiver, complex event processor and profiler, optimization processor, and an action plan applier.

This feature is currently being delivered in Technology Preview and supports a limited number of optimization strategies in this first release. For more information about the Optimize service, see https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/optimizing_infrastructure_resource_utilization/index.

The Optimize service in RHOSO, which was released as a Technology Preview in RHOSO 18.0.6, is now functional as a Technology Preview for the supported strategies in 18.0.7.

Jira:OSPRH-15037

You can now use new metrics for monitoring the health of RHOSO services, including the following:

You can now retrieve the VMs: ceilometer_power_state metric to indicate the libvirt power state.

Jira:OSPRH-10377

You can now use the dashboards to view a dedicated VM Network Traffic Dashboard, as well as monitor the power state of VMs.

Jira:OSPRH-10481

You can now use the dashboards to view the available IPMI sensor hardware metrics from your compute nodes.

Jira:OSPRH-10808

You can now view Compute nodes by human-readable hostnames, instead of with Compute service UUIDs.

Jira:OSPRH-11755

You can now use Telemetry Operator with OpenShift Logging versions 6.1 and newer.

Jira:OSPRH-12147

Telemetry Operator now creates a secret with the internal Prometheus connection details. Other OpenShift services can use that secret as a service discovery mechanism to connect to Prometheus.