Menu Close

Service Telemetry Framework Release Notes 1.4

Red Hat OpenStack Platform 16.1

Release details for Service Telemetry Framework 1.4

OpenStack Documentation Team

Red Hat Customer Content Services


This document outlines the major features, enhancements, and known issues in this release of Service Telemetry Framework.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Chapter 1. Introduction to Service Telemetry Framework release

This release of Service Telemetry Framework (STF) provides new features and resolved issues specific to STF.

STF uses components from other Red Hat products. For specific information pertaining to the support of these components, see and

STF 1.4 is compatible with OpenShift Container Platform (OCP) version 4.7 and 4.8 as the deployment platform.

1.1. Product support

The Red Hat Customer Portal offers resources to guide you through the installation and configuration of Service Telemetry Framework. The following types of documentation are available through the Customer Portal:

  • Product documentation
  • Knowledge base articles and solutions
  • Technical briefs
  • Support case management

    You can access the Customer Portal at

Chapter 2. Service Telemetry Framework release information

Notes for updates released during the supported lifecycle of this Service Telemetry Framework (STF) release appear in the advisory text associated with each update.

2.1. Service Telemetry Framework 1.4

These release notes highlight enhancements and removed functionality to be taken into consideration when you install this release of Service Telemetry Framework (STF).

This release includes the following advisories:

Release of components for Service Telemetry Framework 1.4.0 - Container Images

2.1.1. Enhancements

This release of STF features the following enhancements:

Add the parameter to the ServiceTelemetry manifest so that the Elasticsearch version requested by STF to the Elasticsearch Operator can be specified.
To improve security compliance, you must now authenticate on all user interfaces. As a result, HTTPS routes to Prometheus, Alertmanager, and Grafana are now provided by default when those components deploy. Use OpenShift Container Platform credentials to authenticate to the newly exposed services. Grafana maintains the existing basic-auth login option for backwards-compatibility purposes.

Service Telemetry Framework (STF) now supports a new parameter to the ServiceTelemtry manifest, observabilityStrategy.

Setting the parameter observabilityStrategy to a value of none results in the Service Telemetry Operator deploying the AMQ Interconnect routers, and the Smart Gateways for metrics and sensubility (API monitoring).

When you set the observabilityStrategy parameter to none, the administrator can deploy STF in a minimal configuration, which results in the consumption of telemetry data from Red Hat OpenStack Platform to be exposed in OpenShift Container Platform through the Smart Gateway.

It is currently not possible to deploy the event Smart Gateways in this mode.

2.1.2. Release notes

This section outlines important details about the release, including recommended practices and notable changes to STF. You must take this information into account to ensure the best possible outcomes for your installation.


In this release, the manually-created x-descriptors which provided UI hints to the OpenShift Container Platform user interface within the Operator Lifecycle Manager (OLM) were removed.

The removal of the x-descriptors results in the UI system using the API defined in the CustomResourceDefinition (CRD). Maintaining the UI hints is easier and more of the ServiceTelemetry objects configuration options are exposed to the OLM UI.

As a result, configuring ServiceTelemetry objects, especially in a multiple cloud environment, is easier.

When you install Service Telemetry Framework 1.4, the Service Telemetry Operator no longer requires Operators other than the Smart Gateway Operator to be installed as dependencies. As a result, administrators must now install other dependent Operators if you need to store metrics and events. For more information, see the installation chapter of the Service Telemetry Framework guide.
In this release, the servicemonitorManifest parameter no longer overrides the manifest that is created when Smart Gateways are created by the Service Telemetry Operator. You can now use the servicemonitorManifest parameter to create an additional Service Monitor object without affecting those created for metrics Smart Gateways.

2.1.3. Removed functionality

The following functionality has been removed from this release of STF:


Previously, the Service Telemetry Operator resulted in dependent Operators being installed by Operator Lifecycle Manager when subscribing to the Service Telemetry Operator. That functionality has been removed from this release.

As some of those Operators are outside the scope of the Red Hat Operator CatalogSource (non-productized Operators), they are no longer required for installation of the Service Telemetry Operator. As an administrator deploying Service Telemetry Framework, subscribe to those third-party Operators before you deploy of a ServiceTelemetry object.

Only the Smart Gateway Operator is installed as a dependency of the Service Telemetry Operator.

2.2. Service Telemetry Framework 1.4.1

These release notes highlight enhancements and removed functionality to be taken into consideration when you install this release of Service Telemetry Framework (STF).

2.2.1. Bug fixes

These bugs were fixed in this release of STF:

In some cases, Ceilometer metrics were not handled properly by sg-core. This resulted in some Ceilometer metrics not being stored in Prometheus. In this release, the processing of metrics has been enhanced to be more robust. While the sg-core has been enhanced to support larger messages from Ceilometer, an additional change is required to support passing the larger messages through the sg-bridge ring buffer. The changes required to fully support this functionality is being tracked in RHBZ#2053681.