|
| 1 | +// Module included in the following assemblies: |
| 2 | +// * network_observability/release_notes_archive/network-observability-operator-release-notes-archive.adoc |
| 3 | + |
| 4 | +:_mod-docs-content-type: REFERENCE |
| 5 | +[id="network-observability-release-notes-1-3-0-fixed-issues_{context}"] |
| 6 | += Network observability 1.3.0 fixed issues |
| 7 | + |
| 8 | +[role="_abstract"] |
| 9 | +You can review the following fixed issues in the Network Observability Operator 1.3.0 release. |
| 10 | + |
| 11 | +* Previously, when the Operator was installed from the CLI, the `Role` and `RoleBinding` that are necessary for the {cmo-full} to read the metrics were not installed as expected. The issue did not occur when the operator was installed from the web console. Now, either way of installing the Operator installs the required `Role` and `RoleBinding`. (link:https://issues.redhat.com/browse/NETOBSERV-1003[*NETOBSERV-1003*]) |
| 12 | +
|
| 13 | +* Since version 1.2, the Network Observability Operator can raise alerts when a problem occurs with the flows collection. Previously, due to a bug, the related configuration to disable alerts, `spec.processor.metrics.disableAlerts` was not working as expected and sometimes ineffectual. Now, this configuration is fixed so that it is possible to disable the alerts. (link:https://issues.redhat.com/browse/NETOBSERV-976[*NETOBSERV-976*]) |
| 14 | +
|
| 15 | +* Previously, when network observability was configured with `spec.loki.authToken` set to `DISABLED`, only a `kubeadmin` cluster administrator was able to view network flows. Other types of cluster administrators received authorization failure. Now, any cluster administrator is able to view network flows. (link:https://issues.redhat.com/browse/NETOBSERV-972[*NETOBSERV-972*]) |
| 16 | +
|
| 17 | +* Previously, a bug prevented users from setting `spec.consolePlugin.portNaming.enable` to `false`. Now, this setting can be set to `false` to disable port-to-service name translation. (link:https://issues.redhat.com/browse/NETOBSERV-971[*NETOBSERV-971*]) |
| 18 | +
|
| 19 | +* Previously, the metrics exposed by the console plugin were not collected by the {cmo-full} (Prometheus), due to an incorrect configuration. Now the configuration has been fixed so that the console plugin metrics are correctly collected and accessible from the {product-title} web console. (link:https://issues.redhat.com/browse/NETOBSERV-765[*NETOBSERV-765*]) |
| 20 | +
|
| 21 | +* Previously, when `processor.metrics.tls` was set to `AUTO` in the `FlowCollector`, the `flowlogs-pipeline servicemonitor` did not adapt the appropriate TLS scheme, and metrics were not visible in the web console. Now the issue is fixed for AUTO mode. (link:https://issues.redhat.com/browse/NETOBSERV-1070[*NETOBSERV-1070*]) |
| 22 | +
|
| 23 | +* Previously, certificate configuration, such as used for Kafka and Loki, did not allow specifying a namespace field, implying that the certificates had to be in the same namespace where network observability is deployed. Moreover, when using Kafka with TLS/mTLS, the user had to manually copy the certificate(s) to the privileged namespace where the `eBPF` agent pods are deployed and manually manage certificate updates, such as in the case of certificate rotation. Now, network observability setup is simplified by adding a namespace field for certificates in the `FlowCollector` resource. As a result, users can now install Loki or Kafka in different namespaces without needing to manually copy their certificates in the network observability namespace. The original certificates are watched so that the copies are automatically updated when needed. (link:https://issues.redhat.com/browse/NETOBSERV-773[*NETOBSERV-773*]) |
| 24 | +
|
| 25 | +* Previously, the SCTP, ICMPv4 and ICMPv6 protocols were not covered by the network observability agents, resulting in a less comprehensive network flows coverage. These protocols are now recognized to improve the flows coverage. (link:https://issues.redhat.com/browse/NETOBSERV-934[*NETOBSERV-934*]) |
0 commit comments