Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
c05ab6d
commit 525d6c3
Showing
5 changed files
with
111 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
13 changes: 13 additions & 0 deletions
13
logging/logging_release_notes/logging-5-9-release-notes.adoc
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| :_mod-docs-content-type: ASSEMBLY | ||
| [id="logging-5-9-release-notes"] | ||
| include::_attributes/common-attributes.adoc[] | ||
| = Logging 5.9 | ||
| :context: logging-5-9-release-notes | ||
|
|
||
| toc::[] | ||
|
|
||
| include::snippets/logging-compatibility-snip.adoc[] | ||
|
|
||
| include::snippets/logging-stable-updates-snip.adoc[] | ||
|
|
||
| include::modules/logging-release-notes-5-9-0.adoc[leveloffset=+1] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,92 @@ | ||
| //module included in logging-5-9-release-notes.adoc | ||
| :content-type: REFERENCE | ||
| [id="logging-release-notes-5-9-0_{context}"] | ||
| = Logging 5.9.0 | ||
| This release includes link:https://access.redhat.com/errata/RHBA-2024:1591[OpenShift Logging Bug Fix Release 5.9.0] | ||
|
|
||
| [id="logging-release-notes-5-9-0-removal-notice"] | ||
| == Removal notice | ||
|
|
||
| The {logging-uc} 5.9 release does not contain an updated version of the {es-op}. Instances of {es-op} from prior {logging} releases, remain supported until the EOL of the {logging} release. As an alternative to using the {es-op} to manage the default log storage, you can use the {loki-op}. For more information on the {logging-uc} lifecycle dates, see link:https://access.redhat.com/support/policy/updates/openshift_operators#platform-agnostic[Platform Agnostic Operators]. | ||
|
|
||
| [id="logging-release-notes-5-9-0-deprecation-notice"] | ||
| == Deprecation notice | ||
|
|
||
| * In {logging-uc} 5.9, Fluentd, and Kibana are deprecated and are planned to be removed in {logging-uc} 6.0, which is expected to be shipped alongside a future release of {product-title}. Red Hat will provide critical and above CVE bug fixes and support for these components during the current release lifecycle, but these components will no longer receive feature enhancements. The Vector-based collector provided by the {clo} and LokiStack provided by the {loki-op} are the preferred Operators for log collection and storage. We encourage all users to adopt the Vector and Loki log stack, as this will be the stack that will be enhanced going forward. | ||
|
|
||
| * In {logging-uc} 5.9, *Fields* option in output type Splunk is deprecated and is planned to be removed in a future release. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed. | ||
|
|
||
| [id="logging-release-notes-5-9-0-enhancements"] | ||
| == Enhancements | ||
|
|
||
| [id="logging-release-notes-5-9-0-log-collection"] | ||
| === Log Collection | ||
| * This enhancement adds the ability to refine the process of log collection by using a workload's metadata and to `drop` or `prune` logs based on their content. Additionally, it allows the collection of infrastructure like journal or container logs and audit logs like `kube api` or `ovn` to only collect individual sources. (link:https://issues.redhat.com/browse/LOG-2155[LOG-2155]) | ||
|
|
||
| * With this update, the `ClusterLogForwarder` API now supports log forwarding to Azure Monitor Logs, giving users better monitoring abilities. This feature helps users to maintain optimal system performance and streamline log analysis processes in Azure Monitor, which speeds up issue resolution and improves operational efficiency. (link:https://issues.redhat.com/browse/LOG-4605[LOG-4605]) | ||
|
|
||
| * This enhancement improves collector resource utilization by deploying collectors as a deployment with two replicas. It happens when the only input source defined in the `ClusterLogForwarder` is a receiver input instead of using a daemonset on all nodes. Additionally, collectors deployed like this do not mount the host file system. To use this enhancement, you need to annotate the `ClusterLogForwarder` with `logging.openshift.io/dev-preview-enable-collector-as-deployment`. (link:https://issues.redhat.com/browse/LOG-4779[LOG-4779]) | ||
|
|
||
| * This enhancement introduces the capability for custom tenant configuration across all supported outputs, facilitating the organization of log records in a logical manner. However, it does not permit custom tenant configuration for {logging} managed storage. (link:https://issues.redhat.com/browse/LOG-4843[LOG-4843]) | ||
|
|
||
| * With this update, the `ClusterLogForwarder` that specifies an application input with one or more infrastructure namespaces like `default`, `openshift*`, or `kube*`, now requires a service account with the `collect-infrastructure-logs` role. (link:https://issues.redhat.com/browse/LOG-4943[LOG-4943]) | ||
|
|
||
| * This enhancement introduces the capability for tuning some output settings like compression, retry duration, and max payloads, to match characteristics of the receiver. Additionally, this feature includes a delivery mode to allow administrators to choose between throughput and log durability. For example, `AtLeastOnce` configures minimal disk buffering of collected logs so that the collector can deliver those logs after a restart. (link:https://issues.redhat.com/browse/LOG-5026[LOG-5026]) | ||
|
|
||
| * This enhancement adds three new Prometheus alerts, warning users about the deprecation of Elasticsearch, Fluentd, and Kibana. (link:https://issues.redhat.com/browse/LOG-5055[LOG-5055]) | ||
|
|
||
| [id="logging-release-notes-5-9-0-log-storage"] | ||
| === Log Storage | ||
| * This enhancement introduces support for short-lived token workload identity federation with Azure and AWS log stores for STS enabled {product-title} 4.14 and later clusters. Local storage requires the addition of a `CredentialMode: static` annotation under `spec.storage.secret` in the LokiStack CR. (link:https://issues.redhat.com/browse/LOG-4540[LOG-4540]) | ||
|
|
||
| * With this update, the validation of the Azure storage secret is now extended to give early warning for certain error conditions. (link:https://issues.redhat.com/browse/LOG-4571[LOG-4571]) | ||
|
|
||
| [id="logging-release-notes-5-9-0-bug-fixes"] | ||
| == Bug Fixes | ||
| * Before this update, the {logging} must-gather could not collect any logs on the FIPS enabled cluster. With this update, a new `oc` client is available in `cluster-logging-rhel9-operator`, and must-gather works properly on FIPS clusters. (link:https://issues.redhat.com/browse/LOG-4403[LOG-4403]) | ||
|
|
||
| * Before this update, the LokiStack ruler pods could not format the IPv6 pod IP in HTTP URLs used for cross-pod communication. This issue caused querying rules and alerts through the Prometheus-compatible API to fail. With this update, the LokiStack ruler pods encapsulate the IPv6 pod IP in square brackets, resolving the problem. Now, querying rules and alerts through the Prometheus-compatible API works just like in IPv4 environments. (link:https://issues.redhat.com/browse/LOG-4709[LOG-4709]) | ||
|
|
||
| * Before this fix, the YAML content from the {logging} must-gather was exported in a single line, making it unreadable. With this update, the YAML white spaces are preserved, ensuring that the file is properly formatted. (link:https://issues.redhat.com/browse/LOG-4792[LOG-4792]) | ||
|
|
||
| * Before this update, changing a `LogQL` query that used controls such as time range or severity changed the label matcher operator defining it like a regular expression. With this update, regular expression operators remain unchanged when updating the query. (link:https://issues.redhat.com/browse/LOG-4810[LOG-4810]) | ||
|
|
||
| * Before this update, the {loki-op} did not mount a custom CA bundle to the ruler pods. As a result, during the process to evaluate alerting or recording rules, object storage access failed. With this update, the {loki-op} mounts the custom CA bundle to all ruler pods. The ruler pods can download logs from object storage to evaluate alerting or recording rules. (link:https://issues.redhat.com/browse/LOG-4830[LOG-4830]) | ||
|
|
||
| * Before this update, forwarding with a legacy forwarder to an internal LokiStack would produce SSL/TLS certificate errors using Vector collector pods. With this update, the log collector service account is used by default for authentication and also using the associated token and `ca.crt``. (link:https://issues.redhat.com/browse/LOG-4881[LOG-4881]) | ||
|
|
||
| * Before this update, the collector could fail with an `x509 certificate verification` failure when forwarding logs to Loki on an IPv6 cluster. With this update, the environment variable is set from `KUBERNETES_SERVICE_HOST` to `kubernetes.default.svc` to resolve this issue. (link:https://issues.redhat.com/browse/LOG-4884[LOG-4884]) | ||
|
|
||
| * Before this update, when configured to read a custom S3 Certificate Authority the {loki-op} would not automatically update the configuration when the name of the ConfigMap or the contents changed. With this update, the Loki Operator is watching for changes to the ConfigMap and automatically updates the generated configuration. (link:https://issues.redhat.com/browse/LOG-4897[LOG-4897]) | ||
|
|
||
| * Before this update, the {clo} deployed ClusterRoles supporting LokiStack deployments only when the default log output was LokiStack. With this update, the roles are split into two groups: read and write. The write roles deploys based on the setting of the default log storage, just like all the roles used to do before. The read roles deploys based on whether the logging console plugin is active. (link:https://issues.redhat.com/browse/LOG-4898[LOG-4898]) | ||
|
|
||
| * Before this update, in {OCP} 4.15, the *Ruler* could not send alerts to *Alertmanager* in user workload monitoring because the `openshift-monitoring` team had not updated the necessary RBAC permissions in {OCP} 4.15. With this update, the {loki-op} now has the correct RBAC permissions to send alerts to *Alertmanager* in user workload monitoring in {OCP} 4.15, and it provides these permissions to *Ruler*. (link:https://issues.redhat.com/browse/LOG-4938[LOG-4938]) | ||
|
|
||
| * Before this update, the {logging} view plugin did not allow for custom node placement and tolerations. With this update, defining custom node placements and tolerations has been added to the {logging} view plugin. (link:https://issues.redhat.com/browse/LOG-4939[LOG-4939]) | ||
|
|
||
| * Before this update, when the `ClusterLogForwarder` was enabled, the {clo} could run into a nil pointer exception when `ClusterLogging.Spec.Collection` was nil. With this update, the issue is now resolved in the {clo}. (link:https://issues.redhat.com/browse/LOG-5006[LOG-5006]) | ||
|
|
||
| * Before this update, in specific corner cases, replacing the `ClusterLogForwarder` status field caused the `resourceVersion` to constantly update due to changing timestamps in `Status` conditions. As a result, it led to an infinite reconciliation loop. With this update, all status conditions synchronize, so that timestamps remain unchanged if conditions stay the same. (link:https://issues.redhat.com/browse/LOG-5007[LOG-5007]) | ||
|
|
||
| * Before this update, running a query for log metrics caused an error in the histogram. With this update, the histogram toggle function and the chart are disabled and hidden because the histogram does not work with log metrics. (link:https://issues.redhat.com/browse/LOG-5048[LOG-5048]) | ||
|
|
||
| * Before this update, there was an internal buffering behavior to `drop_newest` to address high memory consumption by the collector resulting in significant log loss. With this update, the behavior reverts to using the collector defaults. (link:https://issues.redhat.com/browse/LOG-5123[LOG-5123]) | ||
|
|
||
| * Before this update, the Red Hat build pipeline did not use the existing build details in Loki builds and omitted information such as revision, branch, and version. With this update, the Red Hat build pipeline now adds these details to the Loki builds, fixing the issue. (link:https://issues.redhat.com/browse/LOG-5192[LOG-5192]) | ||
|
|
||
| * Before this update, the configuration of the {loki-op}'s `ServiceMonitor` could match many Kubernetes services, resulting in the {loki-op}'s metrics being collected multiple times. With this update, the configuration of `ServiceMonitor` now only matches the dedicated metrics service. (link:https://issues.redhat.com/browse/LOG-5212[LOG-5212]) | ||
|
|
||
| * Before this update, the build pipeline did not include linker flags for the build date, causing Loki builds to show empty strings for `buildDate` and `goVersion`. With this update, adding the missing linker flags in the build pipeline fixes the issue. (link:https://issues.redhat.com/browse/LOG-5261[LOG-5261]) | ||
|
|
||
| [id="logging-release-notes-5-9-0-known-issues"] | ||
| == Known Issues | ||
| None. | ||
|
|
||
| [id="logging-release-notes-5-9-0-CVEs"] | ||
| == CVEs | ||
| * link:https://access.redhat.com/security/cve/CVE-2023-5363[CVE-2023-5363] | ||
| * link:https://access.redhat.com/security/cve/CVE-2023-5981[CVE-2023-5981] | ||
| * link:https://access.redhat.com/security/cve/CVE-2023-46218[CVE-2023-46218] | ||
| * link:https://access.redhat.com/security/cve/CVE-2024-0553[CVE-2024-0553] | ||
| * link:https://access.redhat.com/security/cve/CVE-2024-0567[CVE-2023-0567] |