[enterprise-4.16] OSDOCS-18561 [NETOBSERV] Final Vale Check for March 31 deadline

modules/network-observability-create-network-policy.adoc

@@ -2,13 +2,32 @@
 
 // * networking/network_observability/network-observability-network-policy.adoc
 
+//03/31/2026: Include removed from assembly with 1.10. Remove when network observability docs move to the stand alone format as part of Clean the repo task. DITA changes made to pass Vale checks for March 31 deadline as move to stand alone will happen after March 31 deadline.
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-network-policy_{context}"]
 = Creating a network policy for network observability
 
-If you want to further customize the network policies for the `netobserv` and `netobserv-privileged` namespaces, you must disable the managed installation of the policy from the `FlowCollector` CR, and create your own. You can use the network policy resources that are enabled from the `FlowCollector` CR as a starting point for the procedure that follows:
+[role="_abstract"]
+Customize network policies for the `netobserv` and `netobserv-privileged` namespaces by disabling the managed installation in the FlowCollector resource. Use the default managed policies as a template to create manual network policy configurations that meet specific security requirements.
 
+.Procedure
+. Navigate to *Networking* -> *NetworkPolicies*.
+. Select the `netobserv` project from the *Project* dropdown menu.
+. Name the policy. For this example, the policy name is `allow-ingress`.
+. Click *Add ingress rule* three times to create three ingress rules.
+. Specify the following in the form:
+.. Make the following specifications for the first *Ingress rule*:
+... From the *Add allowed source* dropdown menu, select *Allow pods from the same namespace*.
+.. Make the following specifications for the second *Ingress rule*:
+... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
+... Click *+ Add namespace selector*.
+... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-console`.
+.. Make the following specifications for the third *Ingress rule*:
+... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
+... Click *+ Add namespace selector*.
+... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-monitoring`.
++
 .Example `netobserv` network policy
 [source,yaml]
 ----
@@ -36,7 +55,7 @@ spec:
   policyTypes:
   - Ingress
 ----
-
++
 .Example `netobserv-privileged` network policy
 [source,yaml]
 ----
@@ -56,24 +75,7 @@ spec:
   - Ingress
 ----
 
-.Procedure
-. Navigate to *Networking* -> *NetworkPolicies*.
-. Select the `netobserv` project from the *Project* dropdown menu.
-. Name the policy. For this example, the policy name is `allow-ingress`.
-. Click *Add ingress rule* three times to create three ingress rules.
-. Specify the following in the form:
-.. Make the following specifications for the first *Ingress rule*:
-... From the *Add allowed source* dropdown menu, select *Allow pods from the same namespace*.
-.. Make the following specifications for the second *Ingress rule*:
-... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
-... Click *+ Add namespace selector*.
-... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-console`.
-.. Make the following specifications for the third *Ingress rule*:
-... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
-... Click *+ Add namespace selector*.
-... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-monitoring`.
-
 .Verification
 . Navigate to *Observe* -> *Network Traffic*.
 . View the *Traffic Flows* tab, or any tab, to verify that the data is displayed.
-. Navigate to *Observe* -> *Dashboards*. In the NetObserv/Health selection, verify that the flows are being ingested and sent to Loki, which is represented in the first graph.
+. Navigate to *Observe* -> *Dashboards*. In the NetObserv/Health selection, verify that the flows are being ingested and sent to Loki, which is represented in the first graph.

modules/network-observability-ebpf-flow-data-filtering-examples.adoc

@@ -26,24 +26,28 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        enable: true <1>
+        enable: true
         rules:
-         - action: Accept <2>
-           cidr: 0.0.0.0/0 <3>
-           sampling: 1 <4>
+         - action: Accept
+           cidr: 0.0.0.0/0
+           sampling: 1
          - action: Accept
            cidr: 10.128.0.0/14
-           peerCIDR: 10.128.0.0/14 <5>
+           peerCIDR: 10.128.0.0/14
          - action: Accept
            cidr: 172.30.0.0/16
            peerCIDR: 10.128.0.0/14
            sampling: 50
 ----
-<1> Enables `eBPF` flow filtering by setting `spec.agent.ebpf.flowFilter.enable` to `true`.
-<2> Defines the action for the flow filter rule. Valid values are `Accept` or `Reject`.
-<3> Defines the IP address and `CIDR` mask for the flow filter rule. This parameter supports both `IPv4` and `IPv6` address formats. Use `0.0.0.0/0` for `IPv4` or `::/0` for `IPv6` to match any IP address.
-<4> Defines the sampling interval for matched flows and overrides the global sampling setting (`spec.agent.ebpf.sampling`).
-<5> Filters flows by Peer IP `CIDR`.
+
+where:
+
+`spec.agent.ebpf.flowFilter.enable`:: Specifies whether to enable `eBPF` flow filtering. Set to `true` to enable flow filtering.
+`spec.agent.ebpf.flowFilter.rules.action`:: Specifies the action for the flow filter rule. Valid values are `Accept` or `Reject`.
+`spec.agent.ebpf.flowFilter.rules.cidr`:: Specifies the IP address and `CIDR` mask for the flow filter rule. This parameter supports both `IPv4` and `IPv6` address formats. Use `0.0.0.0/0` for `IPv4` or `::/0` for `IPv6` to match any IP address.
+`spec.agent.ebpf.flowFilter.rules.peerCIDR`:: Specifies the Peer IP `CIDR` used to filter flows.
+`spec.agent.ebpf.flowFilter.rules.sampling`:: Specifies the sampling interval for matched flows. This value overrides the global sampling setting defined in `spec.agent.ebpf.sampling`.
+
 
 [id="example-yaml-filter-flows-with-packet-drops_{context}"]
 == Example YAML to filter flows with packet drops
@@ -62,18 +66,21 @@ spec:
   agent:
     type: eBPF
     ebpf:
-      privileged: true <1>
+      privileged: true
       features:
-        - PacketDrop <2>
+        - PacketDrop
       flowFilter:
-        enable: true <3>
+        enable: true
         rules:
-        - action: Accept <4>
+        - action: Accept
           cidr: 172.30.0.0/16
-          pktDrops: true <5>
+          pktDrops: true
 ----
-<1> Enables packet drops reporting by setting `spec.agent.ebpf.privileged` to `true`.
-<2> Reports packet drops for each network flow by adding the `PacketDrop` value to the `spec.agent.ebpf.features` list.
-<3> Enables `eBPF` flow filtering by setting `spec.agent.ebpf.flowFilter.enable` to `true`.
-<4> Defines the action for the flow filter rule. Valid values are `Accept` or `Reject`.
-<5> Filters flows that contain drops by setting `pktDrops` to `true`.
+
+where:
+
+`spec.agent.ebpf.privileged`:: Specifies whether to enable privileged mode, which is required for reporting packet drops.
+`spec.agent.ebpf.features`:: Specifies the list of eBPF features to enable. Adding the `PacketDrop` value to this list reports packet drops for each network flow.
+`spec.agent.ebpf.flowFilter.enable`:: Specifies whether to enable `eBPF` flow filtering.
+`spec.agent.ebpf.flowFilter.rules.action`:: Specifies the action for the flow filter rule. Valid values are `Accept` or `Reject`.
+`spec.agent.ebpf.flowFilter.rules.pktDrops`:: Specifies whether to filter for flows that contain packet drops.

modules/network-observability-enabling-alerts.adoc

@@ -2,6 +2,8 @@
 //
 // network_observability/network-observability-alerts.adoc
 
+//03/31/2026: Temporary for alerts. Removed from assembly when feature GA'd. Remove file when network observability docs are moved to the stand alone format.
+
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-enabling-alerts_{context}"]
 = Enabling Technology Preview alerts in network observability
@@ -25,7 +27,7 @@ spec:
       env:
         EXPERIMENTAL_ALERTS_HEALTH: "true"
 ----
-
++
 You can still use the existing method for creating alerts. For more information, see "Creating alerts".
 
 //for NetObserv 1.10, specific to new alerts functionality and new health dashboard as a Technology Preview feature. This may or may not be needed when the feature GA's.

modules/network-observability-important-flowcollector-considerations.adoc

@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// network_observability/installing-operators.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="additional-resources_configuring-flow-collector-considerations_{context}"]
+= Important Flow Collector configuration considerations
+
+[role="_abstract"]
+Review essential `FlowCollector` configuration options before initial deployment to avoid pod disruptions caused by later reconfiguration. Key settings include Kafka integration, enriched flow data exports, SR-IOV traffic monitoring, and advanced tracking for DNS and packet drops.
+
+When you create the `FlowCollector` instance, you can reconfigure it, but the pods are terminated and recreated again, which can be disruptive.
+
+Therefore, you can consider configuring the following options when creating the `FlowCollector` for the first time.
+
+//03/20/2026: Comment for JTBD work. This will likely need to be addressed and redone for JTBD. This file was created only to meet the ConceptLink rule by the deadline.

modules/network-observability-operator-release-notes-1-10-advisory.adoc

@@ -6,7 +6,7 @@
 = Network Observability Operator 1.10 advisory
 
 [role="_abstract"]
-Review the advisory that is available for the Network Observability Operator 1.10:
+You can review the advisory for Network Observability Operator 1.10 release.
 
 * link:https://access.redhat.com/errata/RHEA-2025:19153[RHEA-2025:19153 Network Observability Operator 1.10]
 

modules/network-observability-operator-release-notes-1-10-technology-preview-features.adoc

@@ -5,6 +5,9 @@
 [id="network-observability-operator-release-notes-1-10-technology-preview-features_{context}"]
 = Network Observability Operator 1.10 Technology Preview features
 
+[role="_abstract"]
+You can review the Technology Preview features for Network Observability Operator 1.10 release.
+
 [id="network-observability-operator-custom-alerts-technology-preview_{context}"]
 == Network Observability Operator custom alerts (Technology Preview)
 This release introduces new alert functionality, and custom alert configuration. These capabilities are Technology Preview features, and must be explicitly enabled.

modules/network-observability-operator-release-notes-1-9-2-advisory.adoc

@@ -5,6 +5,7 @@
 [id="network-observability-operator-release-notes-1-9-2-advisory_{context}"]
 = Network Observability Operator 1.9.2 advisory
 
-The following advisory is available for the Network Observability Operator 1.9.2:
+[role="_abstract"]
+You can review the advisory for Network Observability Operator 1.9.2 release.
 
 * link:https://access.redhat.com/errata/RHEA-2025:14150[RHEA-2025:14150 Network Observability Operator 1.9.2]

modules/network-observability-operator-release-notes-1-9-2-bug-fixes.adoc

@@ -5,4 +5,7 @@
 [id="network-observability-release-notes-1-9-2-bug-fixes_{context}"]
 = Network observability 1.9.2 bug fixes
 
+[role="_abstract"]
+You can review the fixed issues for the Network Observability Operator 1.9.1 release.
+
 * Before this update, {product-title} versions 4.15 and earlier did not support the `TC_ATTACH_MODE` configuration. This led to command-line interface (CLI) errors and prevented the observation of packets and flows. With this release, the Traffic Control eXtension (TCX) hook attachment mode has been adjusted for these older versions. This eliminates `tcx` hook errors and enables flow and packet observation.

modules/network-observability-operator-release-notes-1-9-3-advisory.adoc

@@ -5,6 +5,7 @@
 [id="network-observability-operator-release-notes-1-9-3-advisory_{context}"]
 = Network Observability Operator 1.9.3 advisory
 
-The following advisory is available for the Network Observability Operator 1.9.3:
+[role="_abstract"]
+You can review the advisory for Network Observability Operator 1.9.3 release.
 
 * link:https://access.redhat.com/errata/RHEA-2025:15780[RHEA-2025:15780 Network Observability Operator 1.9.3]

modules/network-observability-predefined-metrics.adoc

@@ -7,7 +7,10 @@
 [id="network-observability-predefined-metrics_{context}"]
 = Predefined metrics
 
+[role="_abstract"]
 Metrics generated by the `flowlogs-pipeline` are configurable in the `spec.processor.metrics.includeList` of the `FlowCollector` custom resource to add or remove metrics.
 ////
 
-//moved to network-observability-metrics-names.adoc
+//moved to network-observability-metrics-names.adoc
+
+//03/31/2026 Remove when network observability docs move to the stand alone format as part of Clean the repo task.

observability/network_observability/installing-operators.adoc

@@ -54,20 +54,16 @@ include::modules/network-observability-operator-install.adoc[leveloffset=+1]
 
 include::modules/network-observability-multitenancy.adoc[leveloffset=+1]
 
-[role="_additional-resources"]
-[id="additional-resources_configuring-flow-collector-considerations"]
-== Important Flow Collector configuration considerations
-Once you create the `FlowCollector` instance, you can reconfigure it, but the pods are terminated and recreated again, which can be disruptive. Therefore, you can consider configuring the following options when creating the `FlowCollector` for the first time:
+include::modules/network-observability-important-flowcollector-considerations.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
 * xref:../../observability/network_observability/configuring-operator.adoc#network-observability-flowcollector-kafka-config_network_observability[Configuring the Flow Collector resource with Kafka]
 * xref:../../observability/network_observability/configuring-operator.adoc#network-observability-enriched-flows_network_observability[Export enriched network flow data to Kafka or IPFIX]
 * xref:../../observability/network_observability/network-observability-secondary-networks.adoc#network-observability-SR-IOV-config_network-observability-secondary-networks[Configuring monitoring for SR-IOV interface traffic]
 * xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-working-with-conversations_nw-observe-network-traffic[Working with conversation tracking]
 * xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-dns-tracking_nw-observe-network-traffic[Working with DNS tracking]
 * xref:../../observability/network_observability/observing-network-traffic.adoc#network-observability-packet-drops_nw-observe-network-traffic[Working with packet drops]
-
-[role="_additional-resources"]
-.Additional resources
 * xref:../../observability/network_observability/flowcollector-api.adoc#network-observability-flowcollector-api-specifications_network_observability[Flow Collector API Reference]
 * xref:../../observability/network_observability/configuring-operator.adoc#network-observability-flowcollector-view_network_observability[Flow Collector sample resource]
 * xref:../../observability/network_observability/configuring-operator.adoc#network-observability-resources-table_network_observability[Resource considerations]

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

@@ -7,12 +7,13 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
+Review new features, enhancements, fixed issues, and known issues for the Network Observability Operator. These release notes provide information to help you understand changes and security advisories in the latest operator release.
+
 The Network Observability Operator enables administrators to observe and analyze network traffic flows for {product-title} clusters.
 
 These release notes track the development of the Network Observability Operator in the {product-title}.
 
-For an overview of the Network Observability Operator, see xref:../../observability/network_observability/network-observability-overview.adoc#network-observability-overview[About network observability].
-
 include::modules/network-observability-operator-release-notes-1-11-1-advisory.adoc[leveloffset=+1]
 
 include::modules/network-observability-operator-release-notes-1-11-1-fixed-issues.adoc[leveloffset=+1]
@@ -24,5 +25,3 @@ include::modules/network-observability-operator-release-notes-1-11-new-features-
 include::modules/network-observability-operator-release-notes-1-11-known-issues.adoc[leveloffset=+1]
 
 include::modules/network-observability-operator-release-notes-1-11-fixed-issues.adoc[leveloffset=+1]
-
-//Purposely missing [role="_abstract"] as it used to ensure Vale is running correctly.

observability/network_observability/troubleshooting-network-observability.adoc

@@ -29,8 +29,6 @@ include::modules/troubleshooting-network-observability-loki-resource-exhausted.a
 
 include::modules/troubleshooting-network-observability-loki-empty-ring.adoc[leveloffset=+1]
 
-== Resource troubleshooting
-
 include::modules/troubleshooting-network-observability-loki-tenant-rate-limit.adoc[leveloffset=+1]
 
 include::modules/troubleshooting-network-observability-loki-large-query-timeout.adoc[leveloffset=+1]