Skip to content

Commit f2fdb47

Browse files
gwynnemonahankalexand-rh
authored andcommitted
[NETOBSERV] Add NETOBSERV-2451 to 1.10 Known Issues
1 parent accd34d commit f2fdb47

File tree

1 file changed

+81
-0
lines changed

1 file changed

+81
-0
lines changed

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

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,69 @@
88
[role="_abstract"]
99
Review the following known issues and their recommended workarounds (where available) that might affect your use of the Network Observability Operator 1.10 release.
1010

11+
[id="upgrading-to-1-10-fails-on-ocp-4-14-and-earlier_{context}"]
12+
== Upgrading to 1.10 fails on {product-title} 4.14 and earlier
13+
14+
Upgrading to the Network Observability Operator 1.10 on {product-title} 4.14 and earlier can fail due to a `FlowCollector` custom resource definition (CRD) validation error in the software catalog.
15+
16+
To workaround this problem, you must:
17+
18+
. Uninstall both versions of the Network Observability Operator from the software catalog in the {product-title} web console.
19+
.. Keep the `FlowCollector` CRD installed so that it doesn't cause any disruption in the flow collection process.
20+
21+
. Check the current name of the `FlowCollector` CRD by running the following command:
22+
+
23+
[source,terminal]
24+
----
25+
$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].name}'
26+
----
27+
+
28+
Expected output:
29+
+
30+
[source,terminal]
31+
----
32+
v1beta1
33+
----
34+
35+
. Check the current serving status of the `FlowCollector` CRD by running the following command:
36+
+
37+
[source,terminal]
38+
----
39+
$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'
40+
----
41+
+
42+
Expected output:
43+
+
44+
[source,terminal]
45+
----
46+
true
47+
----
48+
49+
. Set the `served` flag for the `v1beta1` version to `false` by running the following command:
50+
+
51+
[source,terminal]
52+
----
53+
$ oc patch crd flowcollectors.flows.netobserv.io --type='json' -p "[{'op': 'replace', 'path': '/spec/versions/0/served', 'value': false}]"
54+
----
55+
56+
. Verify that the `served` flag is set to `false` by running the following command:
57+
+
58+
[source,terminal]
59+
----
60+
$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'
61+
----
62+
+
63+
Expected output:
64+
+
65+
[source,terminal]
66+
----
67+
false
68+
----
69+
70+
. Install Network Observability Operator 1.10.
71+
72+
link:https://issues.redhat.com/browse/OCPBUGS-63208[OCPBUGS-63208], link:https://issues.redhat.com/browse/NETOBSERV-2451[NETOBSERV-2451]
73+
1174
[id="eBPF-agent-compatibility-with-older-open-shift-versions_{context}"]
1275
== eBPF agent compatibility with older {product-title} versions
1376
The eBPF agent used in the Network Observability Command Line Interface (CLI) packet capture feature is incompatible with {product-title} versions 4.16 and older.
@@ -17,3 +80,21 @@ This limitation prevents the eBPF-based Packet Capture Agent (PCA) from function
1780
To work around this problem, you must manually configure PCA to use an older, compatible eBPF agent container image. For more information, see the Red Hat Knowledgebase Solution link:https://access.redhat.com/solutions/7132671[eBPF agent compatibility with older Openshift versions in Network Observability CLI 1.10+].
1881

1982
link:https://issues.redhat.com/browse/NETOBSERV-2358[NETOBSERV-2358]
83+
84+
[id="ebpf-agent-fail-to-send-flows-with-openshift-sdn-when-network-policy-enabled_{context}"]
85+
== eBPF Agent fails to send flows with OpenShiftSDN when NetworkPolicy is enabled
86+
87+
When running Network Observability Operator 1.10 on {product-title} 4.14 clusters that use the `OpenShiftSDN` CNI plugin, the eBPF agent is unable to send flow records to the `flowlogs-pipeline` component. This occurs when the `FlowCollector` custom resource is created with `NetworkPolicy` enabled (`spec.networkPolicy.enable: true`).
88+
89+
As a consequence, flow data is not processed by the `flowlogs-pipeline` component and does not appear in the *Network Traffic* dashboard or the configured storage (Loki). The eBPF agent pod logs show `i/o timeout` errors when attempting to connect to the collector:
90+
91+
[source,terminal]
92+
----
93+
time="2025-10-17T13:53:44Z" level=error msg="couldn't send flow records to collector" collector="10.0.68.187:2055" component=exporter/GRPCProto error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.0.68.187:2055: i/o timeout\""
94+
----
95+
96+
To work around this problem, set `spec.networkPolicy.enable` to `false` to disable `NetworkPolicy` in the `FlowCollector` resource for Network Observability Operator 1.10.
97+
98+
This will allow the eBPF agent to communicate with the `flowlogs-pipeline` component without interference from the automatically deployed network policy.
99+
100+
link:https://issues.redhat.com/browse/NETOBSERV-2450[NETOBSERV-2450]

0 commit comments

Comments
 (0)