Netobserv 1.3 release notes and bug fixes

Netobserv 1.3 release notes features and bugs

networking/network_observability/network-observability-operator-release-notes.adoc

@@ -13,15 +13,51 @@ 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.2.0:
+
+* link:https://access.redhat.com/errata/RHSA-2023:110622[RHSA-2023:110622 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. Fore more information, xref:../../networking/network_observability/installing-operators.adoc#network-observability-multi-tenancy_network_observability[Multi-tenancy in Network Observability].
+
+[id="flow-based-dashboard-1.3"]
+==== Flow-based metrics dashboard 
+* This release adds new a 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
+* You can now use must-gather to troubleshoot the Network Observability Operator. For more information, see xref:../../networking/network_observability/troubleshooting-network-observability.adoc#network-observability-must-gather[Network Observability must-gather].
+
+[id="multi-arch-1.3"]
+==== Multiple architectures now supported 
+* The Network Observability Operator now supports multiple architectures: `amd64`, `ppc64le`, or `arm64`. 
+
+[id="network-observability-operator-1.2.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*])
+
 [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
+=== 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.
 
@@ -38,7 +74,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
@@ -51,7 +87,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.
+* 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 occured 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"]
@@ -75,4 +111,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*])