Skip to content

Commit 7b6808b

Browse files
authored
Merge pull request #51173 from libander/RHDEVDOCS-4437
RHDEVDOCS-4437 - 5.6 Logging Release Notes
2 parents 48a0637 + 975ac3f commit 7b6808b

File tree

2 files changed

+91
-4
lines changed

2 files changed

+91
-4
lines changed

logging/cluster-logging-release-notes.adoc

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,17 @@
11
:_content-type: ASSEMBLY
2-
[id="cluster-logging-release-notes_{context}"]
2+
[id="cluster-logging-release-notes"]
33
include::_attributes/common-attributes.adoc[]
44
= Release notes for Logging
55

66
:context: cluster-logging-release-notes-v5x
77

88
toc::[]
99

10-
[id="cluster-logging-ocp-compatibility_{context}"]
11-
.Logging Compatibility
12-
The {logging-title} is provided as an installable component, with a distinct release cycle from the core {product-title}. The link:https://access.redhat.com/support/policy/updates/openshift#logging[Red Hat OpenShift Container Platform Life Cycle Policy] outlines release compatibility.
10+
include::snippets/logging-compatibility-snip.adoc[]
11+
12+
include::snippets/logging-stable-updates-snip.adoc[]
13+
14+
include::modules/cluster-logging-rn-5.6.adoc[leveloffset=+1]
1315

1416
include::modules/cluster-logging-rn-5.5.5.adoc[leveloffset=+1]
1517

modules/cluster-logging-rn-5.6.adoc

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
//included in cluster-logging-release-notes.adoc
2+
:_content-type: ASSEMBLY
3+
[id="cluster-logging-release-notes-5-6_{context}"]
4+
= Logging 5.6
5+
This release includes link:https://access.redhat.com/errata/RHSA-2023:0264[OpenShift Logging Release 5.6].
6+
7+
[id="openshift-logging-5-6-dep-notice_{context}"]
8+
== Deprecation notice
9+
In Logging 5.6, Fluentd 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. As an alternative to fluentd, you can use Vector instead.
10+
11+
[id="openshift-logging-5-6-enhancements_{context}"]
12+
== Enhancements
13+
* With this update, Logging is compliant with {product-title}
14+
xref:../security/tls-security-profiles.adoc[cluster-wide cryptographic policies]. (link:https://issues.redhat.com/browse/LOG-895[LOG-895])
15+
16+
* With this update, you can declare per-tenant, per-stream, and global policies retention policies through the LokiStack custom resource, ordered by priority. (link:https://issues.redhat.com/browse/LOG-2695[LOG-2695])
17+
18+
* With this update, Splunk is an available output option for log forwarding. (link:https://issues.redhat.com/browse/LOG-2913[LOG-2913])
19+
20+
* With this update, Vector replaces Fluentd as the default Collector. (link:https://issues.redhat.com/browse/LOG-2222[LOG-2222])
21+
22+
* With this update, the *Developer* role can access the per-project workload logs they are assigned to within the Log Console Plugin on clusters running {product-title} 4.11 and higher. (link:https://issues.redhat.com/browse/LOG-3388[LOG-3388])
23+
24+
* With this update, logs from any source contain a field `openshift.cluster_id`, the unique identifier of the cluster in which the Operator is deployed. You can view the `clusterID` value with the command below. (link:https://issues.redhat.com/browse/LOG-2715[LOG-2715])
25+
26+
include::snippets/logging-get-clusterid-snip.adoc[lines=9..12]
27+
28+
[id="openshift-logging-5-6-known-issues_{context}"]
29+
== Known Issues
30+
* Before this update, Elasticsearch would reject logs if multiple label keys had the same prefix and some keys included the `.` character. This fixes the limitation of Elasticsearch by replacing `.` in the label keys with `_`. As a workaround for this issue, remove the labels that cause errors, or add a namespace to the label. (link:https://issues.redhat.com/browse/LOG-3463[LOG-3463])
31+
32+
[id="openshift-logging-5-6-bug-fixes_{context}"]
33+
== Bug fixes
34+
* Before this update, if you deleted the Kibana Custom Resource, the {product-title} web console continued displaying a link to Kibana. With this update, removing the Kibana Custom Resource also removes that link. (link:https://issues.redhat.com/browse/LOG-2993[LOG-2993])
35+
36+
* Before this update, a user was not able to view the application logs of namespaces they have access to. With this update, the Loki Operator automatically creates a cluster role and cluster role binding allowing users to read application logs. (link:https://issues.redhat.com/browse/LOG-3072[LOG-3072])
37+
38+
* Before this update, the Operator removed any custom outputs defined in the `ClusterLogForwarder` custom resource when using LokiStack as the default log storage. With this update, the Operator merges custom outputs with the default outputs when processing the `ClusterLogForwarder` custom resource. (link:https://issues.redhat.com/browse/LOG-3090[LOG-3090])
39+
40+
* Before this update, the CA key was used as the volume name for mounting the CA into Loki, causing error states when the CA Key included non-conforming characters, such as dots. With this update, the volume name is standardized to an internal string which resolves the issue. (link:https://issues.redhat.com/browse/LOG-3331[LOG-3331])
41+
42+
* Before this update, a default value set within the LokiStack Custom Resource Definition, caused an inability to create a LokiStack instance without a `ReplicationFactor` of `1`. With this update, the operator sets the actual value for the size used. (link:https://issues.redhat.com/browse/LOG-3296[LOG-3296])
43+
44+
* Before this update, Vector parsed the message field when JSON parsing was enabled without also defining `structuredTypeKey` or `structuredTypeName` values. With this update, a value is required for either `structuredTypeKey` or `structuredTypeName` when writing structured logs to Elasticsearch. (link:https://issues.redhat.com/browse/LOG-3195[LOG-3195])
45+
46+
* Before this update, the secret creation component of the Elasticsearch Operator modified internal secrets constantly. With this update, the existing secret is properly handled. (link:https://issues.redhat.com/browse/LOG-3161[LOG-3161])
47+
48+
* Before this update, the Operator could enter a loop of removing and recreating the collector daemonset while the Elasticsearch or Kibana deployments changed their status. With this update, a fix in the status handling of the Operator resolves the issue. (link:https://issues.redhat.com/browse/LOG-3157[LOG-3157])
49+
50+
* Before this update, Kibana had a fixed `24h` OAuth cookie expiration time, which resulted in 401 errors in Kibana whenever the `accessTokenInactivityTimeout` field was set to a value lower than `24h`. With this update, Kibana's OAuth cookie expiration time synchronizes to the `accessTokenInactivityTimeout`, with a default value of `24h`. (link:https://issues.redhat.com/browse/LOG-3129[LOG-3129])
51+
52+
* Before this update, the Operators general pattern for reconciling resources was to try and create before attempting to get or update which would lead to constant HTTP 409 responses after creation. With this update, Operators first attempt to retrieve an object and only create or update it if it is either missing or not as specified. (link:https://issues.redhat.com/browse/LOG-2919[LOG-2919])
53+
54+
* Before this update, the `.level` and`.structure.level` fields in Fluentd could contain different values. With this update, the values are the same for each field. (link:https://issues.redhat.com/browse/LOG-2819[LOG-2819])
55+
56+
* Before this update, the Operator did not wait for the population of the trusted CA bundle and deployed the collector a second time once the bundle updated. With this update, the Operator waits briefly to see if the bundle has been populated before it continues the collector deployment. (link:https://issues.redhat.com/browse/LOG-2789[LOG-2789])
57+
58+
* Before this update, logging telemetry info appeared twice when reviewing metrics. With this update, logging telemetry info displays as expected. (link:https://issues.redhat.com/browse/LOG-2315[LOG-2315])
59+
60+
* Before this update, Fluentd pod logs contained a warning message after enabling the JSON parsing addition. With this update, that warning message does not appear. (link:https://issues.redhat.com/browse/LOG-1806[LOG-1806])
61+
62+
* Before this update, the `must-gather` script did not complete because `oc` needs a folder with write permission to build its cache. With this update, `oc` has write permissions to a folder, and the `must-gather` script completes successfully. (link:https://issues.redhat.com/browse/LOG-3446[LOG-3446])
63+
64+
* Before this update the log collector SCC could be superseded by other SCCs on the cluster, rendering the collector unusable. This update sets the priority of the log collector SCC so that it takes precedence over the others. (link:https://issues.redhat.com/browse/LOG-3235[LOG-3235])
65+
66+
* Before this update, Vector was missing the field `sequence`, which was added to fluentd as a way to deal with a lack of actual nanoseconds precision. With this update, the field `openshift.sequence` has been added to the event logs. (link:https://issues.redhat.com/browse/LOG-3106[LOG-3106])
67+
68+
[id="openshift-logging-5-6-cves_{context}"]
69+
== CVEs
70+
* https://access.redhat.com/security/cve/CVE-2020-36518[CVE-2020-36518]
71+
* https://access.redhat.com/security/cve/CVE-2021-46848[CVE-2021-46848]
72+
* https://access.redhat.com/security/cve/CVE-2022-2879[CVE-2022-2879]
73+
* https://access.redhat.com/security/cve/CVE-2022-2880[CVE-2022-2880]
74+
* https://access.redhat.com/security/cve/CVE-2022-27664[CVE-2022-27664]
75+
* https://access.redhat.com/security/cve/CVE-2022-32190[CVE-2022-32190]
76+
* https://access.redhat.com/security/cve/CVE-2022-35737[CVE-2022-35737]
77+
* https://access.redhat.com/security/cve/CVE-2022-37601[CVE-2022-37601]
78+
* https://access.redhat.com/security/cve/CVE-2022-41715[CVE-2022-41715]
79+
* https://access.redhat.com/security/cve/CVE-2022-42003[CVE-2022-42003]
80+
* https://access.redhat.com/security/cve/CVE-2022-42004[CVE-2022-42004]
81+
* https://access.redhat.com/security/cve/CVE-2022-42010[CVE-2022-42010]
82+
* https://access.redhat.com/security/cve/CVE-2022-42011[CVE-2022-42011]
83+
* https://access.redhat.com/security/cve/CVE-2022-42012[CVE-2022-42012]
84+
* https://access.redhat.com/security/cve/CVE-2022-42898[CVE-2022-42898]
85+
* https://access.redhat.com/security/cve/CVE-2022-43680[CVE-2022-43680]

0 commit comments

Comments
 (0)