Skip to content

Commit

Permalink
Netobserv 1.3 release notes and bug fixes
Browse files Browse the repository at this point in the history 
Netobserv 1.3 release notes features and bugs
  • Loading branch information
@skrthomas
skrthomas committed Jun 28, 2023
1 parent eaa11d0 commit 0a68f37
Showing 1 changed file with 57 additions and 6 deletions.
63 changes: 57 additions & 6 deletions networking/network_observability/network-observability-operator-release-notes.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -13,16 +13,68 @@ These release notes track the development of the Network Observability Operator

For an overview of the Network Observability Operator, see xref:../../networking/network_observability/network-observability-overview.adoc#dependency-network-observability[About Network Observability Operator].

[id="network-observability-operator-release-notes-1-3"]
== Network Observability Operator 1.3.0
The following advisory is available for the Network Observability Operator 1.3.0:

* link:https://access.redhat.com/errata/RHSA-2023:3905[RHSA-2023:3905 Network Observability Operator 1.3.0]

[id="network-observability-operator-1.3.0-features-enhancements"]
=== New features and enhancements

[id="multi-tenancy-1.3"]
==== Multi-tenancy in Network Observability
* System administrators can allow and restrict individual user access, or group access, to the flows stored in Loki. For more information, see xref:../../networking/network_observability/installing-operators.adoc#network-observability-multi-tenancynetwork_observability[Multi-tenancy in Network Observability].

[id="flow-based-dashboard-1.3"]
==== Flow-based metrics dashboard
* This release adds a new dashboard, which provides an overview of the network flows in your {product-title} cluster. For more information, see xref:../../networking/network_observability/network-observability-overview.adoc#network-observability-dashboards[Network Observability metrics].

[id="must-gather-1.3"]
==== Troubleshooting with the must-gather tool
* Information about the Network Observability Operator can now be included in the must-gather data for troubleshooting. For more information, see xref:../../networking/network_observability/troubleshooting-network-observability.adoc#troubleshooting-network-observability-must-gather_network-observability-troubleshooting[Network Observability must-gather].

[id="multi-arch-1.3"]
==== Multiple architectures now supported
* Network Observability Operator can now run on an amd64, ppc64le, or arm64 architecture. Previously, it only ran on amd64.

[id="deprecated-features-1.3"]
=== Deprecated features

[id="authToken-host"]
==== Deprecated configuration parameter setting
The release of Network Observability Operator 1.3 deprecates the `spec.Loki.authToken` `HOST` setting. When using the Loki Operator, you must now only use the `FORWARD` setting.

[id="network-observability-operator-1.3.0-bug-fixes"]
=== Bug fixes
* Previously, when the Operator was installed from the CLI, the `Role` and `RoleBinding` that are necessary for the Cluster Monitoring Operator 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*])

* 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*])

* 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*])

* 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*])

* Previously, the metrics exposed by the console plugin were not collected by the Cluster Monitoring Operator (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*])

* 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*])

* 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*])

* 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*])

[id="network-observability-operator-1.3.0-known-issues"]
=== Known issue
* When `processor.metrics.tls` is set to `PROVIDED` in the `FlowCollector`, the `flowlogs-pipeline` `servicemonitor` is not adapted to the TLS scheme. (link:https://issues.redhat.com/browse/NETOBSERV-1087[NETOBSERV-1087])

[id="network-observability-operator-release-notes-1-2"]
== Network Observability Operator 1.2.0

The following advisory is available for the Network Observability Operator 1.2.0:

* https://access.redhat.com/errata/RHSA-2023:1817[RHSA-2023:1817 Network Observability Operator 1.2.0]

[id="network-observability-operator-preparing-to-update"]
=== Preparing for the next update

The subscription of an installed Operator specifies an update channel that tracks and receives updates for the Operator. Until the 1.2 release of the Network Observability Operator, the only channel available was `v1.0.x`. The 1.2 release of the Network Observability Operator introduces the `stable` update channel for tracking and receiving updates. You must switch your channel from `v1.0.x` to `stable` to receive future Operator updates. The `v1.0.x` channel is deprecated and planned for removal in a following release.

[id="network-observability-operator-1.2.0-features-enhancements"]
Expand All @@ -38,7 +90,7 @@ The subscription of an installed Operator specifies an update channel that track

[id="health-alerts-feature-1.2"]
==== Network Observability health alerts
* The Network Observability Operator now creates automatic alerts if the `flowlogs-pipeline` is dropping flows because of errors at the write stage or if the Loki ingestion rate limit has been reached. For more information, see xref:../../networking/network_observability/network-observability-operator-monitoring.adoc#network-observability-alert-dashboard_network_observability[Viewing health information].
* The Network Observability Operator now creates automatic alerts if the `flowlogs-pipeline` is dropping flows because of errors at the write stage or if the Loki ingestion rate limit has been reached. For more information, see xref:../../networking/network_observability/network-observability-operator-monitoring.adoc#network-observability-alert-dashboard_network_observability[Viewing health information].

[id="network-observability-operator-1.2.0-bug-fixes"]
=== Bug fixes
Expand All @@ -51,8 +103,7 @@ The subscription of an installed Operator specifies an update channel that track

* The "reporter" option in the console plug-in is used to filter flows based on the observation point of either source node or destination node. Previously, this option mixed the flows regardless of the node observation point. This was due to network flows being incorrectly reported as Ingress or Egress at the node level. Now, the network flow direction reporting is correct. The "reporter" option filters for source observation point, or destination observation point, as expected. (link:https://issues.redhat.com/browse/NETOBSERV-696[*NETOBSERV-696*])

* Previously, for agents configured to send flows directly to the processor as gRPC+protobuf requests, the submitted payload could be too large and is rejected by the processors' GRPC server. This occurred under very-high-load scenarios and with only some configurations of the agent. The agent logged an error message, such as: _grpc: received message larger than max_. As a consequence, there was information loss about those flows.
Now, the gRPC payload is split into several messages when the size exceeds a threshold. As a result, the server maintains connectivity. (link:https://issues.redhat.com/browse/NETOBSERV-617[*NETOBSERV-617*])
* Previously, for agents configured to send flows directly to the processor as gRPC+protobuf requests, the submitted payload could be too large and is rejected by the processors' GRPC server. This occurred under very-high-load scenarios and with only some configurations of the agent. The agent logged an error message, such as: _grpc: received message larger than max_. As a consequence, there was information loss about those flows. Now, the gRPC payload is split into several messages when the size exceeds a threshold. As a result, the server maintains connectivity. (link:https://issues.redhat.com/browse/NETOBSERV-617[*NETOBSERV-617*])

[id="network-observability-operator-1.2.0-known-issues"]
=== Known issue
Expand All @@ -75,4 +126,4 @@ The Network Observability Operator is now stable and the release channel is upgr
=== Bug fix

* Previously, unless the Loki `authToken` configuration was set to `FORWARD` mode, authentication was no longer enforced, allowing any user who could connect to the {product-title} console in an {product-title} cluster to retrieve flows without authentication.
Now, regardless of the Loki `authToken` mode, only cluster administrators can retrieve flows. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2169468[*BZ#2169468*])
Now, regardless of the Loki `authToken` mode, only cluster administrators can retrieve flows. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2169468[*BZ#2169468*])

0 comments on commit 0a68f37

Please sign in to comment.