STF 1.3 does not support the infra.watch/v1alpha1 Custom Resource Definition and now supports infra.watch/v1beta1.

In STF 1.2, the infra.watch/v1alpha1 interface was deprecated and the Service Telemetry Operator supported a translation to infra.watch/v1beta1 dynamically. As of STF 1.3, this support has been removed and only infra.watch/v1beta1 is supported. Ensure that you migrate to infra.watch/v1beta1 before you upgrade from STF 1.2 to STF 1.3.

Ceilometer metrics are distributed internally within Red Hat OpenStack Platform (RHOSP) via the RabbitMQ bus, collected via the ceilometer agents, and transported to STF for storage in Prometheus via sg-core.

Before this release, if you set up the RHOSP environment in high-availability mode, each controller collected and sent metrics with a publisher label containing the controller name. As a result, ceilometer metrics that looked broken were written to Prometheus.

This update drops the publisher label on ceilometer metrics to collapse the ceilometer metrics to a single set of labels. As a result, metrics from ceilometer no longer appear to be broken up across multiple publishers.

Previous queries that relied on the publisher label might not work. You can override the default ServiceMonitor object with the servicemonitorManifest parameter in the ServiceTelemetry object.

Before this update, Ceilometer metrics exposed by sg-core resulted in virtual machine instances having their ID exposed as a label value host. As a result, using the label host overloaded the drop-down menu in the dashboards with virtual machine instances in addition to the node instances.

With this update, Ceilometer virtual machine instance metrics use the vm_instance label to expose the instance ID of a virtual machine so that virtual machine instance IDs are not listed in the STF dashboard node instance drop-down menu.

Before this release, documentation referred to clouds: {} to provide an empty object to result in no Smart Gateways being deployed. As a result, Smart Gateways did not clear and the following error was seen in the logs of the Service Telemetry Operator:

"Invalid data passed to loop, it requires a list, got this instead: {}. Hint: If you passed a list/dict of just one element, try adding wantlist=True to your lookup invocation or use q/query instead of lookup."

Documentation now states that clouds: [] is the correct format, resulting in an empty list being passed rather than an empty object. As a result, no Smart Gateways are defined.

Use of the redhat-operators-stf CatalogSource has been removed from the documentation of Service Telemetry Framework v1.3. It was used to install a copy of the AMQ Certificate Manager Operator as a workaround to the unavailable Operator in OpenShift Container Platform versions beyond v4.5.

The AMQ Certificate Operator is again available in the redhat-operators CatalogSource from OpenShift Container Platform v4.7, meaning the use of the additional CatalogSource is no longer necessary.

To migrate to the built in AMQ Certificate Manager v1.0.1, complete the following steps:

Previously, when you installed STF without having Elastic Cloud on Kubernetes (ECK) Operator installed, the following error message was returned: "Failed to find exact match for elasticsearch.k8s.elastic.co/v1beta1.Elasticsearch". The error was as a result of Service Telemetry Operator trying to look up information from a non-existent API interface.

With this update, the Service Telemetry Operator verifies that the API exists before it attempts to make requests to the API interface that is provided by ECK.

Before this update, the query for high CPU usage in the alerts.yaml was invalid. Additionally, the rhos-dashboard showed pending alerts in the global alerts panels, resulting in false positives, meaning that high CPU warning and critical alarms could trigger falsely or not trigger when high CPU usage was detected.

With this release, the high CPU alert query uses the new recording rules by calculating the sum of CPU usage grouped by host and dividing those values by the number of cores for that host, resulting in a CPU usage between 0 and 100%.