Chapter 1. New and enhanced features

This section provides an overview of features that have been added to or significantly enhanced in this release of Red Hat OpenStack Services on OpenShift (RHOSO).

RHOSO improves substantially over previous versions of Red Hat OpenStack Platform (RHOSP). The RHOSO control plane is natively hosted on the Red Hat OpenShift Container Platform (RHOCP) and the external RHEL-based data plane and workloads are managed with Ansible. This shift in architecture aligns with Red Hat’s platform infrastructure strategy. You can future proof your existing investments by using RHOCP as a hosting platform for all of your infrastructure services.

RHOSP 17.1 is the last version of the product to use the director-based OpenStack on OpenStack form-factor for the control plane.

1.1. Control plane new and enhanced features

Control plane deployed on Red Hat OpenShift Container Platform (RHOCP)

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:

Deployed in pods and governed by Kubernetes Operators.
Deploys in minutes, consuming only a fraction of the CPU and RAM footprint required by earlier RHOSP releases.
Takes advantage of native Kubernetes mechanisms for high availability.
Features built-in monitoring based on RHOCP Observability.

1.2. Data plane new and enhanced features

Ansible-managed data plane

The director-deployed overcloud is replaced by a data plane driven by the OpenStack Operator and executed by Ansible. RHOSO data plane features include:

The OpenStackDataPlaneNodeSet custom resource definition (CRD), which provides a highly parallel deployment model.
Micro failure domains based on the OpenStackDataPlaneNodeSet CRD. If one or more node sets fail, the other node sets run to completion because there is no interdependency between node sets.
Faster deployment times compared to previous RHOSP versions.
Highly configurable data plane setup based on the OpenStackDataPlaneNodeSet and OpenStackDataPlaneService CRDs.

1.3. Distributed Compute nodes (DCN)

DCN with Red Hat Ceph storage: RHOSO 18.0.3 (Feature Release 1) introduces support for Distributed Compute Nodes (DCN) with persistent storage backed by Red Hat Ceph Storage.

1.4. Networking new and enhanced features

Dynamic routing on data plane with FRR and BGP

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.

Limitations:

If you use dynamic routing, you must also use distributed virtual routing (DVR).
If you use dynamic routing, you also use dedicated networker nodes.
You can not use dynamic routing in an IPv6 deployment or a deployment that uses the Load-balancing service (octavia).

Custom ML2 mechanism driver and SDN backend (Technology Preview)

RHOSO 18.0.3 (Feature Release 1) allows you to test integration of the Networking service (neutron) with a custom ML2 mechanism driver and software defined networking (SDN) back end components, instead of the default OVN mechanism driver and back end components. Do not use this feature in a production environment.

IPv6 metadata

RHOSO 18.0.3 (Feature Release 1) introduces support of the IPv6 metadata service.

NMstate provider for os-net-config (Development Preview)

RHOSO 18.0.3 (Feature Release 1) allows you to test a Development Preview of the NMstate provider for os-net-config. To test the NMstate provider, set edpm_network_config_nmstate: true. Do NOT use this Development Preview setting in a production environment.

Forwarding database (FDB) learning and aging controls

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.

Example configuration

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

Egress QoS support at NIC level using DCB (Technology Preview)

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.

Configuring and deploying networking with Kubernetes NMState Operator and the RHEL NetworkManager service (Technology preview)

The RHOSO bare-metal network deployment uses os-net-config with a Kubernetes NMState Operator and NetworkManager back end. Therefore, administrators can use the Kubernetes NMState Operator, nmstate, and the RHEL NetworkManager CLI tool nmcli to configure and deploy networks on the data plane, instead of legacy ifcfg files and network-init-scripts.

1.5. Storage new and enhanced features

Integration with external Red Hat Ceph Storage (RHCS) 7 clusters: You can integrate RHOSO with external RHCS 7 clusters to include RHCS capabilities with your deployment.
Distributed image import: RHOSO 18.0 introduces distributed image import for the Image service (glance). With this feature, you do not need to configure a shared staging area for different API workers to access images that are imported to the Image service. Now the API worker that owns the image data is the same API worker that performs the image import.
Block Storage service (cinder) backup and restore for thin volumes: The backup service for the Block Storage service service now preserves sparseness when restoring a backup to a new volume. This feature ensures that restored volumes use the same amount of storage as the backed up volume. It does not apply to RBD backups, which use a different mechanism to preserve sparseness.
Support for RHCS RBD deferred deletion: RHOSO 18.0 introduces Block Storage service and Image service RBD deferred deletion, which improves flexibility in the way RBD snapshot dependencies are managed. With deferred deletion, you can delete a resource such as an image, volume, or snapshot even if there are active dependencies.
Shared File Systems service (manila) CephFS NFS driver with Ganesha Active/Active: The CephFS-NFS driver for the Shared File Systems service now consumes an active/active Ganesha cluster by default, improving both the scalability and high availability of the Ceph NFS service.
Unified OpenStack client parity with native Shared File Systems service client: The Shared File Systems service now fully supports the openstack client command line interface.

1.6. Security new and enhanced features

This section outlines the top new and enhanced features for RHOSO security services.

FIPS enabled by default

Federal Information Processing Standard (FIPS) is enabled by default when RHOSO is installed on a FIPS enabled RHOCP cluster in new deployments.
You do not enable or disable FIPS in your RHOSO configuration. You control the FIPS state in the underlying RHOCP cluster.

TLS-everywhere enabled by default

After deployment, you can configure public services with your own certificates. You can deploy without TLS-everywhere and enable it later. You cannot disable TLS-everywhere after you enable it.

Secure RBAC enabled by default

The Secure Role-Based Access Control (RBAC) policy framework is enabled by default in RHOSO deployments.

Key Manager (barbican) enabled by default

The Key Manager is enabled by default in RHOSO deployments.

1.7. High availability new and enhanced features

High availability managed natively in RHOCP: RHOSO high availability (HA) uses RHOCP primitives instead of RHOSP services to manage failover and recovery deployment.

1.8. Upgrades new and enhanced features

Adoption from RHOSP 17.1: RHOSO 18.0.3 (Feature Release 1) introduces the ability to use the adoption mechanism to upgrade from RHOSP 17.1 to RHOSO 18.0 while minimizing impacts to your workloads.

1.9. Observability new and enhanced features

Power consumption monitoring (Technology Preview

RHOSO 18.0.3 (Feature Release 1) introduces technology previews of power consumption monitoring capability for VM instances and 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).

RabbitMQ metrics dashboard

Starting in RHOSO 18.0.3 (Feature Release 1), RabbitMQ metrics are collected and stored in Prometheus. A new dashboard for displaying these metrics was added.

Enhanced Openstack Observability

Enhanced dashboards provide unified observability with visualizations that are natively integrated into the RHOCP Observability UI. These include the node_exporter agent that exposes metrics to the Prometheus monitoring system.
In RHOSO 18.0, the node_exporter agent replaces the collectd daemon, and Prometheus replaces the Time series database (Gnocchi).

Logging

The OpenStack logging capability is significantly enhanced. You can now collect logs from the Scontrol plane and Compute nodes, and use RHOCP Logging to store them in-cluster via Loki log store or forward them off-cluster to an external log store. Logs that are stored in-cluster with Loki can be visualized in the RHOCP Observability UI console.

Service Telemetry Framework deprecation

The Observability product for previous versions of RHOSP is Service Telemetry Framework (STF). With the release of RHOSO 18.0, STF is Deprecated and in maintenance mode. There are no feature enhancements for STF after STF 1.5.4, and STF status reaches end of life at the end of the RHOSP 17.1 lifecycle. Maintenance versions of STF will be released on new EUS versions of RHOCP until the end of the RHOSP 17.1 lifecycle.

1.10. Dashboard new and enhanced features

Pinned CPUs: The OpenStack Dashboard service (horizon) now shows how many pinned CPUs (pCPUs) are used and available to use in your environment.

1.11. Documentation new and enhanced features

The documentation library has been restructured to align with the user lifecycle of RHOSO. Each guide incorporates content from one or more product areas that work together to cover end-to-end tasks. The titles are organized in categories for each stage in the user lifecycle of RHOSO.

1.11.1. Documentation categories

The following categories are published with RHOSO 18.0:

Plan

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

Release notes
Planning your deployment
Integrating partner content

Prepare, deploy, configure, test

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:

Deploying Red Hat OpenStack Services on OpenShift
Customizing the Red Hat OpenStack Services on OpenShift deployment
Deploying a Network Functions Virtualization environment
Deploying a hyper-converged infrastructure environment
Configuring persistent storage
Validating and troubleshooting the deployed cloud

Adopt and update

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:

Adopting a Red Hat OpenStack Platform 17.1 overcloud to a Red Hat OpenStack Services on OpenShift 18.0 data plane
Updating your environment to the latest maintenance release

Customize and scale

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:

Configuring the Compute service for instance creation
Configuring data plane networking
Configuring load balancing as a service
Customizing persistent storage
Configuring security services
Auto-scaling for instances

Manage resources and maintain the cloud

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

Maintaining the Red Hat OpenStack Services on OpenShift deployment
Creating and managing instances
Performing storage operations
Performing security operations
Managing networking resources
Managing cloud resources with the Dashboard
Monitoring high availability services

1.11.2. Documentation in progress

The following titles are being reviewed and will be published asynchronously:

Configuring the Bare Metal Provisioning service
Configuring load balancing as a service (Technology Preview)

1.11.3. RHOCP feature documentation

Features that are supported and managed natively in RHOCP are documented in the RHOCP documentation library. The RHOSO documentation includes links to relevant RHOCP documentation where needed.

1.11.4. Earlier documentation versions

The RHOSO documentation page shows documentation for version 18.0 and later. For earlier supported versions of RHOSP, see Product Documentation for Red Hat OpenStack Platform 17.1.