Rename network-observability-operator -> netobserv-operator

.mk/development.mk

@@ -188,7 +188,7 @@ endif
 
 .PHONY: pprof
 pprof:
-	@echo -e "\n==> Enabling pprof... Check https://github.com/netobserv/network-observability-operator/blob/main/DEVELOPMENT.md#profiling for help."
+	@echo -e "\n==> Enabling pprof... Check https://github.com/netobserv/netobserv-operator/blob/main/DEVELOPMENT.md#profiling for help."
 	kubectl -n $(NAMESPACE) set env deployment netobserv-controller-manager -c "manager" PROFILING_BIND_ADDRESS=:6060
 	@echo -e "\n==> Redeploying..."
 	kubectl rollout status -n $(NAMESPACE) --timeout=60s deployment netobserv-controller-manager

.tekton/network-observability-operator-bundle-ystream-pull-request.yaml

@@ -2,7 +2,7 @@ apiVersion: tekton.dev/v1
 kind: PipelineRun
 metadata:
   annotations:
-    build.appstudio.openshift.io/repo: https://github.com/netobserv/network-observability-operator?rev={{revision}}
+    build.appstudio.openshift.io/repo: https://github.com/netobserv/netobserv-operator?rev={{revision}}
     build.appstudio.redhat.com/commit_sha: '{{revision}}'
     build.appstudio.redhat.com/pull_request_number: '{{pull_request_number}}'
     build.appstudio.redhat.com/target_branch: '{{target_branch}}'

.tekton/network-observability-operator-bundle-ystream-push.yaml

@@ -2,7 +2,7 @@ apiVersion: tekton.dev/v1
 kind: PipelineRun
 metadata:
   annotations:
-    build.appstudio.openshift.io/repo: https://github.com/netobserv/network-observability-operator?rev={{revision}}
+    build.appstudio.openshift.io/repo: https://github.com/netobserv/netobserv-operator?rev={{revision}}
     build.appstudio.redhat.com/commit_sha: '{{revision}}'
     build.appstudio.redhat.com/target_branch: '{{target_branch}}'
     pipelinesascode.tekton.dev/max-keep-runs: "3"

.tekton/network-observability-operator-ystream-pull-request.yaml

@@ -2,7 +2,7 @@ apiVersion: tekton.dev/v1
 kind: PipelineRun
 metadata:
   annotations:
-    build.appstudio.openshift.io/repo: https://github.com/netobserv/network-observability-operator?rev={{revision}}
+    build.appstudio.openshift.io/repo: https://github.com/netobserv/netobserv-operator?rev={{revision}}
     build.appstudio.redhat.com/commit_sha: '{{revision}}'
     build.appstudio.redhat.com/pull_request_number: '{{pull_request_number}}'
     build.appstudio.redhat.com/target_branch: '{{target_branch}}'

.tekton/network-observability-operator-ystream-push.yaml

@@ -3,7 +3,7 @@ kind: PipelineRun
 metadata:
   annotations:
     build.appstudio.openshift.io/build-nudge-files: hack/nudging/container_digest.sh
-    build.appstudio.openshift.io/repo: https://github.com/netobserv/network-observability-operator?rev={{revision}}
+    build.appstudio.openshift.io/repo: https://github.com/netobserv/netobserv-operator?rev={{revision}}
     build.appstudio.redhat.com/commit_sha: '{{revision}}'
     build.appstudio.redhat.com/target_branch: '{{target_branch}}'
     pipelinesascode.tekton.dev/max-keep-runs: "3"

AGENTS.md

@@ -14,7 +14,7 @@ Best practices for AI coding agents on NetObserv Operator.
   flow generation from packets (DaemonSet)
 - **[flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline)**: Flow
   collection, enrichment, export (Deployment/StatefulSet) -
-  **[Console Plugin](https://github.com/netobserv/network-observability-console-plugin)**:
+  **[Console Plugin](https://github.com/netobserv/netobserv-web-console)**:
   OpenShift visualization (optional)
 - **CRD**: `FlowCollector` v1beta2 - **single cluster-wide resource named
   `cluster`**

DEVELOPMENT.md

@@ -344,7 +344,7 @@ This workflow is triggered when something is merged into `main`, to push new ima
 git push upstream HEAD:workflow-test -f
 ```
 
-Then, open the [action page](https://github.com/netobserv/network-observability-operator/actions/workflows/push_image.yml) in Github to monitor the jobs triggered. Make sure on Quay that you get the expected images for the [Operator](https://quay.io/repository/netobserv/network-observability-operator?tab=tags), the [bundle](https://quay.io/repository/netobserv/network-observability-operator-bundle?tab=tags) and the [catalog](https://quay.io/repository/netobserv/network-observability-operator-catalog?tab=tags).
+Then, open the [action page](https://github.com/netobserv/netobserv-operator/actions/workflows/push_image.yml) in Github to monitor the jobs triggered. Make sure on Quay that you get the expected images for the [Operator](https://quay.io/repository/netobserv/network-observability-operator?tab=tags), the [bundle](https://quay.io/repository/netobserv/network-observability-operator-bundle?tab=tags) and the [catalog](https://quay.io/repository/netobserv/network-observability-operator-catalog?tab=tags).
 
 Expected images:
 - Operator's tagged "workflow-test" manifest + every support archs
@@ -364,7 +364,7 @@ git push origin HEAD:dummy
 Then, open a PR in github, making sure to select `workflow-test` as the base branch and not `main`.
 On the PR, add the `ok-to-test` label.
 
-This will trigger the corresponding `push_image_pr.yml` workflow ([view on github](https://github.com/netobserv/network-observability-operator/actions/workflows/push_image_pr.yml)). As above, you should check that the images are well created in Quay:
+This will trigger the corresponding `push_image_pr.yml` workflow ([view on github](https://github.com/netobserv/netobserv-operator/actions/workflows/push_image_pr.yml)). As above, you should check that the images are well created in Quay:
 
 Expected images:
 - Operator's tagged with SHA manifest + single arch amd64 (make sure they expire)
@@ -379,7 +379,7 @@ git tag -a "0.0.0-rc0" -m "0.0.0-rc0"
 git push upstream --tags
 ```
 
-When the tag is pushed, it will trigger the corresponding workflow ([view on github](https://github.com/netobserv/network-observability-operator/actions/workflows/release.yml)). As above, you should check that the images are well created in Quay. It's fine if you tag from the `workflow-test` branch (or any branch).
+When the tag is pushed, it will trigger the corresponding workflow ([view on github](https://github.com/netobserv/netobserv-operator/actions/workflows/release.yml)). As above, you should check that the images are well created in Quay. It's fine if you tag from the `workflow-test` branch (or any branch).
 
 Expected images:
 - Operator's tagged 0.0.0-rc0 manifest + every support archs

FAQ.md

@@ -1,6 +1,6 @@
 # F.A.Q / Troubleshooting
 
-If you can't find help here, don't hesitate to open [an issue](https://github.com/netobserv/network-observability-operator/issues) or a [Q&A](https://github.com/netobserv/network-observability-operator/discussions/categories/q-a). There are several repositories under _netobserv_ github org, but it is fine to centralize these in _network-observability-operator_.
+If you can't find help here, don't hesitate to open [an issue](https://github.com/netobserv/netobserv-operator/issues) or a [Q&A](https://github.com/netobserv/netobserv-operator/discussions/categories/q-a). There are several repositories under _netobserv_ github org, but it is fine to centralize these in _network-observability-operator_.
 
 ## Table of Contents
 
@@ -20,34 +20,6 @@ If you can't find help here, don't hesitate to open [an issue](https://github.co
 
 ## Q&A
 
-### Is it for OpenShift only?
-
-No! While some features are developed primarily for OpenShift, we want to keep it on track with other / "vanilla" Kubes. For instance, there has been some work to make the console plugin [run as a standalone](https://github.com/netobserv/network-observability-console-plugin/pull/163), or the operator to manage upstream (non-OpenShift) [ovn-kubernetes](https://github.com/netobserv/network-observability-operator/pull/97).
-
-And if something is not working as hoped with your setup, you are welcome to contribute to the project ;-)
-
-### Which version of Kubernetes / OpenShift is supported?
-
-All versions of Kubernetes since 1.22 should work, although there is no official support (best effort).
-
-All versions of OpenShift currently supported by Red Hat are supported. Older version, greater than 4.10, should also work although not being officially supported (best effort).
-
-Some features depend on the Linux kernel version in use. It should be at least 4.18 (earlier versions have never been tested). More recent kernels (> 5.14) are better, for agent feature completeness and improved performances.
-
-### How do I visualize flows and metrics?
-
-For OpenShift users, a visualization tool is integrated in the OpenShift console. Just open the console in your browser, and you will see new menu items (such as Network Traffic under Observe) once NetObserv is installed and configured.
-
-Non-OpenShift users can deploy the standalone console, as explained in the Getting Started section from the readme.
-
-Alternatively, you can still access the data (Loki logs, Prometheus metrics) in different ways:
-
-- Querying Loki (or Prometheus) directly
-- Using the Prometheus console
-- Using and configuring Grafana
-
-All these options depend on how you installed these components.
-
 ### How can I make sure everything is correctly deployed?
 
 Make sure all pods are up and running:
@@ -109,7 +81,7 @@ If using IPFIX (ie. `spec.agent.type` is `IPFIX` in FlowCollector), wait 10 minu
 
 Else, check for any suspicious error in logs, especially in the `flowlogs-pipeline` pods and the eBPF agent pods. You may also take a look at prometheus metrics prefixed with `netobserv_`: they can give you clues if flows are processed, if errors are reported, etc.
 
-Finally, don't hesitate to [open an issue](https://github.com/netobserv/network-observability-operator/issues).
+Finally, don't hesitate to [open an issue](https://github.com/netobserv/netobserv-operator/issues).
 
 ### There is no Network Traffic menu entry in OpenShift Console
 
@@ -182,7 +154,7 @@ With Loki queries, a first thing to understand is that, while Loki allows to que
 
 Depending on what you are trying to get, you may as well **consider querying Prometheus rather than Loki**. Queries on Prometheus are much faster than on Loki, it should not struggle with large time ranges, hence should be favored whenever possible. But Prometheus metrics do not contain as much information as flow logs in Loki, so whether or not you can do that really depends on the use case. When you use the NetObserv console plugin, it will try automatically to favor Prometheus over Loki if the query is compatible; else it falls back to Loki. If your query does't run against Prometheus, changing some filters or aggregations can make the switch. In the console plugin, you can force the use of Prometheus. Incompatible queries will fail, and the error message displayed should help you figure out which labels you can try to change to make the query compatible (for instance, changing a filter or an aggregation from Resource/Pods to Owner).
 
-If the data that you need isn't available as a Prometheus metric, you may also **consider using the [FlowMetrics API](https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md#custom-metrics-using-the-flowmetrics-api)** to create your own metric. You need to be careful about the metrics cardinality, as explained in this link.
+If the data that you need isn't available as a Prometheus metric, you may also **consider using the [FlowMetrics API](https://github.com/netobserv/netobserv-operator/blob/main/docs/Metrics.md#custom-metrics-using-the-flowmetrics-api)** to create your own metric. You need to be careful about the metrics cardinality, as explained in this link.
 
 If the problem persists, there are ways to **configure Loki to improve the query performance**. Some options depend on the installation mode you used for Loki (using the Operator and `LokiStack`, or `Monolithic` mode, or `Microservices` mode):
 

PROJECT

@@ -8,15 +8,15 @@ layout:
 plugins:
   manifests.sdk.operatorframework.io/v2: {}
 projectName: netobserv-operator
-repo: github.com/netobserv/network-observability-operator
+repo: github.com/netobserv/netobserv-operator
 resources:
 - api:
     crdVersion: v1
   controller: true
   domain: netobserv.io
   group: flows
   kind: FlowCollector
-  path: github.com/netobserv/network-observability-operator/api/flowcollector/v1beta2
+  path: github.com/netobserv/netobserv-operator/api/flowcollector/v1beta2
   version: v1beta2
   webhooks:
     conversion: false
@@ -33,7 +33,7 @@ resources:
   domain: netobserv.io
   group: flows
   kind: FlowMetric
-  path: github.com/netobserv/network-observability-operator/api/flowmetrics/v1alpha1
+  path: github.com/netobserv/netobserv-operator/api/flowmetrics/v1alpha1
   version: v1alpha1
   webhooks:
     validation: true
@@ -44,6 +44,6 @@ resources:
   domain: netobserv.io
   group: flows
   kind: FlowCollectorSlice
-  path: github.com/netobserv/network-observability-operator/api/flowcollectorslice/v1alpha1
+  path: github.com/netobserv/netobserv-operator/api/flowcollectorslice/v1alpha1
   version: v1alpha1
 version: "3"

README.md

@@ -2,7 +2,7 @@
 
 ![GitHub release (latest by date)](https://img.shields.io/github/v/release/netobserv/network-observability-operator)
 [![Artifact HUB](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/NetObserv)](https://artifacthub.io/packages/helm/netobserv/netobserv-operator)
-[![Go Report Card](https://goreportcard.com/badge/github.com/netobserv/network-observability-operator)](https://goreportcard.com/report/github.com/netobserv/network-observability-operator)
+[![Go Report Card](https://goreportcard.com/badge/github.com/netobserv/netobserv-operator)](https://goreportcard.com/report/github.com/netobserv/netobserv-operator)
 
 NetObserv Operator is a Kubernetes operator for network observability. It deploys a monitoring pipeline that consists in:
 - An eBPF agent, that generates network flows from captured packets.
@@ -91,7 +91,7 @@ EOF
 ```
 
 A few remarks:
-- 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 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/netobserv-operator/blob/main/docs/FlowCollector.md#flowcollectorspecprometheus-1) and [Loki](https://github.com/netobserv/netobserv-operator/blob/main/docs/FlowCollector.md#flowcollectorspecloki-1).
 - Depending on the Kubernetes distribution and CNI, NetObserv may come secured by default with a built-in network policy. You can force installing it or not by setting `spec.networkPolicy.enable` in `FlowCollector`. If the built-in policy does not work as intended, it is recommended to turn it off and create your own instead. NetObserv runs some highly privileged workloads, thus it is important to keep it as much isolated as possible. See [NetworkPolicy.md](./docs/NetworkPolicy.md) for more details on how to create a policy.
 - 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).
 
@@ -108,7 +108,7 @@ Then open http://localhost:9001/ in your browser.
 A couple of `make` targets are provided in this repository to allow installing without OLM:
 
 ```bash
-git clone https://github.com/netobserv/network-observability-operator.git && cd network-observability-operator
+git clone https://github.com/netobserv/netobserv-operator.git && cd network-observability-operator
 USER=netobserv make deploy deploy-loki deploy-grafana
 ```
 

RELEASE.md

@@ -4,7 +4,7 @@
 
 All components deployed by this operator can be released separatly, at their own pace.
 
-To release them, a tag in the format "v1.6.0-community" or "v1.6.0-crc0" must be set on the desired clean HEAD state (generally, up-to-date `main` branch; "crc" stands for "community release candidate"), then pushed. It applies to [the console plugin](https://github.com/netobserv/network-observability-console-plugin/), [flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline) and [netobserv-ebpf-agent](https://github.com/netobserv/netobserv-ebpf-agent).
+To release them, a tag in the format "v1.6.0-community" or "v1.6.0-crc0" must be set on the desired clean HEAD state (generally, up-to-date `main` branch; "crc" stands for "community release candidate"), then pushed. It applies to [the console plugin](https://github.com/netobserv/netobserv-web-console/), [flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline) and [netobserv-ebpf-agent](https://github.com/netobserv/netobserv-ebpf-agent).
 
 E.g:
 
@@ -35,7 +35,7 @@ git tag -a "$version" -m "$version"
 git push upstream --tags
 ```
 
-The release script should be triggered ([check github actions](https://github.com/netobserv/network-observability-operator/actions)).
+The release script should be triggered ([check github actions](https://github.com/netobserv/netobserv-operator/actions)).
 
 ### Testing
 
@@ -105,7 +105,7 @@ git push upstream :$test_branch
 ### Publish releases - related components
 
 Use the github interface to accept the releases, via:
-- [console plugin](https://github.com/netobserv/network-observability-console-plugin/releases)
+- [console plugin](https://github.com/netobserv/netobserv-web-console/releases)
 - [flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline/releases)
 - [netobserv-ebpf-agent](https://github.com/netobserv/netobserv-ebpf-agent/releases)
 
@@ -125,7 +125,7 @@ If you think the "Dependencies" section is too long, you can surround it in a `<
 ### Publish releases - operator
 
 Use the github interface to accept the release, via:
-- [operator](https://github.com/netobserv/network-observability-operator/releases)
+- [operator](https://github.com/netobserv/netobserv-operator/releases)
 
 Edit the draft, set the previous tag then click the "Generate release notes" button. Like previously, don't hesitate to surround Dependencies in a `<details>` block.
 

api/flowcollector/v1beta2/flowcollector_alert_types.go

@@ -49,7 +49,7 @@ type FLPHealthRule struct {
 	// Possible values are: `PacketDropsByKernel`, `PacketDropsByDevice`, `IPsecErrors`, `NetpolDenied`,
 	// `LatencyHighTrend`, `DNSErrors`, `DNSNxDomain`, `ExternalEgressHighTrend`, `ExternalIngressHighTrend`, `Ingress5xxErrors`, `IngressHTTPLatencyTrend`.
 	// Note: `NetObservNoFlows` and `NetObservLokiError` are alert-only and cannot be used as health rules.
-	// More information on health rules: https://github.com/netobserv/network-observability-operator/blob/main/docs/HealthRules.md
+	// More information on health rules: https://github.com/netobserv/netobserv-operator/blob/main/docs/HealthRules.md
 	// +kubebuilder:validation:Enum:="PacketDropsByKernel";"PacketDropsByDevice";"IPsecErrors";"NetpolDenied";"LatencyHighTrend";"DNSErrors";"DNSNxDomain";"ExternalEgressHighTrend";"ExternalIngressHighTrend";"Ingress5xxErrors";"IngressHTTPLatencyTrend"
 	// +required
 	Template HealthRuleTemplate `json:"template,omitempty"`