Chapter 1. New and enhanced features

The documentation library page was restructured to align better with the user life cycle and top-level jobs. The new structure includes the following enhancements:

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. With the FWaaS Technology Preview, you can also test NGFW 3rd party plugins for integration with NGFW vendor solutions enabling firewall capabilities beyond the ACL level, including capabilities such as DPI, Malware protection, IPS, and IDP.

In RHOSO 18.0.14 (Feature Release 4), you can test a Technology Preview of TAP-as-a-Service (TAPaaS). Do not use technology preview features in production environments. As modern cloud infrastructure becomes increasingly complex and multi-tenant, observability and security monitoring have become foundational requirements for OpenStack operators. One key network diagnostic technique used in traditional and virtualized environments is port mirroring, which allows administrators to capture and analyze traffic flowing through a particular interface. Mirrored traffic can be re-directed to third party analytics tools and solutions hosted on a different or same host as the mirror port. Typically, the mirrored traffic is carried over overlay tunnels established between the source and destination of the mirror.

You can perform the following tasks with port mirroring:

Port mirroring is available at OVS and OVN levels through a CLI interface, however, in highly dynamic, software-defined environments like OpenStack, traditional port mirroring does not scale well and does not offer the tenant-level abstraction and isolation. 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.

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.

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.6 (Feature Release 2), you can use new metrics for monitoring the health of RHOSO services, including the following:

RHOSO 18.0.3 (Feature Release 1) introduces support of Free Range Routing (FRR) border gateway protocol (BGP) to provide dynamic routing capabilities on the RHOSO data plane.

RHOSO 18.0.3 (Feature Release 1) introduces FDB learning and related FDB aging parameters.

You can use FDB learning to prevent traffic flooding on ports that have port security disabled. Set localnet_learn_fdb to true.

Use the fdb_age_threshold parameter to set the maximum time (seconds) that the learned MACs stay in the FDB table. Use the fdb_removal_limit parameter to prevent OVN from removing a large number of FDB table entries at the same time.

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
    name: unused
spec:
    neutron:
        template:
            customServiceConfig: |
               [ovn]
               localnet_learn_fdb = true
               fdb_age_threshold = 300
               [ovn_nb_global]
               fdb_removal_limit = 50

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
    name: unused
spec:
    neutron:
        template:
            customServiceConfig: |
               [ovn]
               localnet_learn_fdb = true
               fdb_age_threshold = 300
               [ovn_nb_global]
               fdb_removal_limit = 50

RHOSO 18.0.3 (Feature Release 1) introduces technology previews of power consumption monitoring capability for VM instances and virtual networking functions (VNFs).

See Jira Issue OSPRH-10006: Kepler Power Monitoring Metrics Visualization in RHOSO (Tech Preview) and Jira Issue OSPRH-46549: As a service provider I need a comprehensive dashboard that provides a power consumption matrix per VNF(Tech Preview).

In RHOSO 18.0 (GA), the director-based undercloud is replaced by a control plane that is natively hosted on an RHOCP cluster and managed with the OpenStack Operator. The Red Hat OpenStack Services on OpenShift (RHOSO) control plane features include:

In RHOSO 18.0 (GA), the director-deployed overcloud is replaced by a data plane driven by the OpenStack Operator and executed by Ansible. RHOSO data plane features include:

Information about the release, requirements, and how to get started before deployment. This category includes the following guides:

Procedures for deploying an initial RHOSO environment, customizing the control plane and data plane, configuring validated architectures, storage, and testing the deployed environment. This category includes the following guides:

Information about performing minor updates to the latest maintenance release of RHOSO, and procedures for adopting a Red Hat OpenStack Platform 17.1 cloud. This category includes the following guides:

Procedures for configuring and customizing specific components of the deployed environment. These procedures must be done before you start to operate the deployment. This category includes the following guides:

Procedures that you can perform during ongoing operation of the RHOSO environment. This category includes the following guides:

Starting with RHOSO 18.0 (GA), egress quality of service (QoS) at the network interface controller (NIC) level uses the Data Center Bridging Capability Exchange (DCBX) protocol to configure egress QoS at the NIC level in the host. It triggers the configuration and provides the information directly from the top of rack (ToR) switch that peers with the host NIC. This capability, combined with egress QoS for OVS/OVN, enables end-to-end egress QoS.

This is a Technology Preview feature. A Technology Preview feature might not be fully implemented and tested. Some features might be absent, incomplete, or not work as expected.

For more information on this feature, see Feature Integration document - DCB for E2E QoS.