even more netutrality

Author: jotak

README.md

@@ -20,7 +20,9 @@ Flow data is then available in multiple ways, each optional:
 You can install the NetObserv Operator using [Helm](https://helm.sh/), or directly from sources.
 
 > [!TIP]
-> If you are running on OpenShift, please refer to the [product documentation](https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/installing-network-observability-operators) instead. NetObserv is referred to as the Network Observability operator there.
+NetObserv can be used in downstream products, which may provide their own documentation. If you are using such a product, please refer to that documentation instead:
+> 
+> - On OpenShift: [see Network Observability operator](https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/installing-network-observability-operators).
 
 ### Pre-requisite
 
@@ -56,8 +58,6 @@ helm install my-netobserv -n netobserv --create-namespace --set install.loki=tru
 
 # OR minimal install (Prometheus/Loki must be installed separately)
 helm install my-netobserv -n netobserv --create-namespace netobserv/netobserv-operator
-
-# If you're in OpenShift, you can use "--set standaloneConsole.enable=false" to use the Console plugin instead.
 ```
 
 You can now create a `FlowCollector` resource. Refer to the [Configuration section](#configuration) of this document. A short `FlowCollector` should work, using most default values, plus with the standalone console enabled:
@@ -93,7 +93,6 @@ EOF
 ```
 
 A few remarks:
-- `spec.consolePlugin.standalone` can be set to true to deploy the [web console](https://github.com/netobserv/network-observability-console-plugin) as a standalone.
 - You can change the Prometheus and Loki URLs depending on your installation. This example works if you use the "standalone" installation described above, with `install.loki=true` and `install.prom-stack=true`. Check more configuration options for [Prometheus](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowcollectorspecprometheus-1) and [Loki](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowcollectorspecloki-1).
 - You can enable networkPolicy, which makes the operator lock down the namespaces that it manages; however, this is highly dependent on your cluster topology, and may cause malfunctions, such as preventing NetObserv pods from communicating with the Kube API server.
 - The processor env `SERVER_NOTLS` means that the communication between eBPF agents and Flowlogs-pipeline won't be encrypted. To enable TLS, you need to supply the TLS certificates to Flowlogs-pipeline (a Secret named `flowlogs-pipeline-cert`), and the CA to the eBPF agents (a ConfigMap named `flowlogs-pipeline-ca` in the privileged namespace). [Check this issue](https://github.com/netobserv/network-observability-operator/issues/2360) if you want to help making it simpler.
@@ -141,7 +140,7 @@ Historically, Grafana Loki was a strict dependency but it isn't anymore. If you
 
 ### Web Console
 
-When `FlowCollector` is installed, a standalone web console is deployed or, if running in OpenShift, an OpenShift Console plugin. It provides the following views:
+When `FlowCollector` is installed, a standalone web console is deployed or, when available, a console plugin. It provides the following views:
 
 #### Overview metrics
 
@@ -257,7 +256,7 @@ More information about multi-tenancy can be found on [this page](https://github.
 
 For a production deployment, it is highly recommended to lock down the `netobserv` namespace (or wherever NetObserv is installed) using network policies.
 
-You can set `spec.networkPolicy.enable` to `true` to make NetObserv install automatically a network policy. The policy may need to be fined-tuned for your environment (e.g. for access to kube apiserver, or Prometheus). It has been mostly tested on OpenShift with OVN-Kubernetes.
+You can set `spec.networkPolicy.enable` to `true` to make NetObserv install automatically a network policy. The policy may need to be fined-tuned for your environment (e.g. for access to kube apiserver, or Prometheus), by adding authorized namespaces.
 
 A simple example of network policy is [provided here](https://github.com/netobserv/documents/blob/main/examples/lockdown-netobserv.yaml).
 

helm/README.md

@@ -52,8 +52,6 @@ helm install my-netobserv -n netobserv --create-namespace --set install.loki=tru
 
 # OR minimal install (Prometheus/Loki must be installed separately)
 helm install my-netobserv -n netobserv --create-namespace netobserv/netobserv-operator
-
-# If you're in OpenShift, you can use "--set standaloneConsole.enable=false" to use the Console plugin instead.
 ```
 
 You can now create a `FlowCollector` resource ([full API reference](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowsnetobserviov1beta2)). A short `FlowCollector` should work, using most default values, plus with the standalone console enabled:
@@ -89,7 +87,6 @@ EOF
 ```
 
 A few remarks:
-- `spec.consolePlugin.standalone` can be set to true to deploy the [web console](https://github.com/netobserv/network-observability-console-plugin) as a standalone.
 - You can change the Prometheus and Loki URLs depending on your installation. This example works if you use the "standalone" installation described above, with `install.loki=true` and `install.prom-stack=true`. Check more configuration options for [Prometheus](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowcollectorspecprometheus-1) and [Loki](https://github.com/netobserv/network-observability-operator/blob/main/docs/FlowCollector.md#flowcollectorspecloki-1).
 - You can enable networkPolicy, which makes the operator lock down the namespaces that it manages; however, this is highly dependent on your cluster topology, and may cause malfunctions, such as preventing NetObserv pods from communicating with the Kube API server.
 - The processor env `SERVER_NOTLS` means that the communication between eBPF agents and Flowlogs-pipeline won't be encrypted. To enable TLS, you need to supply the TLS certificates to Flowlogs-pipeline (a Secret named `flowlogs-pipeline-cert`), and the CA to the eBPF agents (a ConfigMap named `flowlogs-pipeline-ca` in the privileged namespace).