Adds bug fixes to Network Observability 1.2 release notes

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

@@ -26,4 +26,41 @@ 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*])
+
+//Content from https://github.com/openshift/openshift-docs/pull/56051 builds 1.2 release section header and note about updating. Once that PR is merged, I'll rebase this one and pull in the header so the information below will follow.//
+
+[id="network-observability-operator-1.2.0-features-enhancements"]
+=== New features and enhancements
+
+[id="histogram-feature-1.2]
+==== Histogram in Traffic Flows view
+* You can now choose to show a histogram bar chart of flows over time. The bar chart enables you to visualize the history of flows without hitting the Loki query limit.
+<link>
+
+[id="conversation-tracking-feature-1.2]
+==== Conversation tracking
+* You can now query flows by *Log Type*, which enables grouping network flows by that are part of the same conversation. For more information, see xref:../../networking/network_observability/observing-network-traffic.adoc#network-observability-working-with-conversations_nw-observe-network-traffic[Working with conversations]
+
+[id="conversation-tracking-feature-1.2]
+==== Network Observability health alerts
+* The Network Observability Operator now creates automatic alerts if the `flowlogs-pipeline` is dropping flows because of Loki errors or if the Loki ingestion rate limit has been reached. For more information, see xref:../../networking/network_observability/network-observability-monitoring.adoc#network-observability-viewing-alerts_network-observability[Viewing health information]. 
+
+[id="network-observability-operator-1.2.0-bug-fixes"]
+=== Bug fixes
+
+* Previously, after changing the `namespace` value in the FlowCollector spec, eBPF Agent pods running in the previous namespace were not appropriately deleted. Now, the pods running in the previous namespace are appropriately deleted. (link:https://issues.redhat.com/browse/NETOBSERV-774[NETOBSERV-774])
+
+* Previously, after changing the `caCert.name` value in the FlowCollector spec (such as in Loki section), FlowLogs-Pipeline pods and Console plugin pods were not restarted, therefore they were unaware of the configuration change. Now, the pods are restarted, so they get the configuration change. (link:https://issues.redhat.com/browse/NETOBSERV-772[NETOBSERV-772])
+
+* Previously, network flows between pods running on different nodes were sometimes not correctly identified as being duplicates because they are captured by different network interfaces. This resulted in over-estimated metrics displayed in the console plugin. Now, flows are correctly identified as duplicates, and the console plugin displays accurate metrics. (link:https://issues.redhat.com/browse/NETOBSERV-755[NETOBSERV-755])
+
+* Previously, the "reporter" option in the console plugin, which is used to filter flows based on the observation point of either source node or destination node, 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 corrected. 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, when using TLS, the console plug-in, agent, and flowlogs-pipeline got certificates from a mounted config map or secret. If a certificate was replaced, the mounted value inside the pods was not updated, forcing the pods to continue using the old certificates. As a consequence, the console plug-in, agent, or flowlogs-pipeline could lose connectivity to services such as Loki or Kafka.
+Now, the certificate content is watched, and a change triggers restarting the pods that mounted those certificates with new volumes configured. As a result, connectivity to Loki or Kafka is automatically restored. (link:https://issues.redhat.com/browse/NETOBSERV-684[NETOBSERV-684])
+
+* 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 connectivity is maintained. (link:https://issues.redhat.com/browse/NETOBSERV-617[NETOBSERV-617])
+
+* Previously, custom namespaces were supported. Custom namespaces are no longer supported. You cannot automatically upgrade to the new Operator version if you previously installed the Network Observability Operator using a custom namespace. You must delete the instances of the Operator using the cusom namespace and re-install your operator in the `openshift-netobserv-operator` namespace. (link:https://issues.redhat.com/browse/NETOBSERV-907[NETOBSERV-907])