diff --git a/.github/workflows/docs-build.yml b/.github/workflows/docs-build.yml
index 44d36c7ad..cc22d3549 100644
--- a/.github/workflows/docs-build.yml
+++ b/.github/workflows/docs-build.yml
@@ -24,6 +24,10 @@ jobs:
go-version: '1.21' # yamllint disable-line rule:quoted-strings
- name: Install dependencies
run: |
+ sudo apt-get update
+ sudo apt-get install -qy \
+ libxml2-dev \
+ libxslt-dev \
python -m pip install --upgrade pip
pip install -r requirements.txt
diff --git a/docs/developer-guide/develop-operator.md b/docs/developer-guide/develop-operator.md
index 5c0887371..864e3e99e 100644
--- a/docs/developer-guide/develop-operator.md
+++ b/docs/developer-guide/develop-operator.md
@@ -1,20 +1,26 @@
# Developing the bpfman-operator
This section is intended to give developer level details regarding the layout and design of the bpfman-operator.
-At its core the operator was implemented using the [operator-sdk framework](https://sdk.operatorframework.io/)
+At its core the operator was implemented using the [operator-sdk framework](https://sdk.operatorframework.io/),
which make those docs another good resource if anything is missed here.
## High level design overview
-This repository houses two main processes, the `bpfman-agent` and the `bpfman-operator` along with CRD api definitions
+This repository houses two main processes, the `bpfman-agent` and the `bpfman-operator`, along with CRD api definitions
for `BpfProgram` and `*Program` Objects.
The following diagram depicts how all these components work together to create a functioning operator.
+The `bpfman-operator` is running as a Deployment with a ReplicaSet of one.
+It runs on the control plane and is composed of the containers `bpfman-operator` and
+`kube-rbac-proxy`.
+The operator is responsible for launching the bpfman Daemonset, which runs on every node.
+The bpfman Daemonset is composed of the containers `bpfman`, `bpfman-agent`, and `node-driver-registrar`.
+
## Building and Deploying
-For building and deploying the bpfman-operator simply see the attached `make help`
+For building and deploying the bpfman-operator, simply see the attached `make help`
output.
```bash
@@ -62,7 +68,6 @@ Build
load-images-kind Load bpfman-agent, and bpfman-operator images into the running local kind devel cluster.
bundle-build Build the bundle image.
bundle-push Push the bundle image.
- catalog-update Generate catalog yaml file.
catalog-build Build a catalog image.
catalog-push Push a catalog image.
@@ -94,15 +99,15 @@ The following is a brief description of the main directories under `bpfman-opera
**NOTE: Bolded directories contain auto-generated code**
-- `apis/v1alpha1/*_types.go`: Contains the K8s CRD api definitions (`*_types.go`) for each version.
+- `apis/v1alpha1/*_types.go`: Contains the K8s CRD api definitions (`*_types.go`) for each program type.
- **apis/v1alpha1/zz_generated.*.go**: Contains the auto-generated register (`zz_generate.register.go`)
- and deepcopy (`zz_generated.deepcopy.go`) methods.
-- `bundle/`: Contains the OLM bundle manifests and metadata for the operator.
+ and deep copy (`zz_generated.deepcopy.go`) methods.
+- **bundle/**: Contains the bundle manifests and metadata for the operator.
More details can be found in the operator-sdk documentation.
- `cmd/`: Contains the main entry-points for the bpfman-operator and bpfman-agent processes.
- `config/`: Contains the configuration files for launching the bpfman-operator on a cluster.
- - `bpfman-deployment/`: Contains static deployment yamls for the bpfman-daemon, this includes two containers,
- one for `bpfman` and the other for the `bpfman-agent`.
+ - `bpfman-deployment/`: Contains static deployment yamls for the bpfman-daemon.
+ This includes two containers, one for `bpfman` and the other for the `bpfman-agent`.
This DaemonSet yaml is NOT deployed statically by kustomize, instead it's statically copied into the operator
image which is then responsible for deploying and configuring the bpfman-daemon DaemonSet.
Lastly, this directory also contains the default config used to configure the bpfman-daemon, along with the
@@ -110,8 +115,8 @@ The following is a brief description of the main directories under `bpfman-opera
- `bpfman-operator-deployment/`: Contains the static deployment yaml for the bpfman-operator.
This is deployed statically by kustomize.
- `crd/`: Contains the CRD manifests for all of the bpfman-operator APIs.
- - **bases/**: Is where the actual CRD definitions are stored.
- These definitions are auto-generated by [controller-gen](https://book.kubebuilder.io/reference/controller-gen.html).
+ - **bases/**: This is where the actual CRD definitions are stored.
+ These definitions are auto-generated by [controller-gen](https://book.kubebuilder.io/reference/controller-gen.html).
- `patches/`: Contains kustomize patch files for each Program Type, which enables a conversion webhook for
the CRD and adds a directive for certmanager to inject CA into the CRD.
- `default/`: Contains the default deployment configuration for the bpfman-operator.
@@ -119,12 +124,12 @@ The following is a brief description of the main directories under `bpfman-opera
- `openshift/`: Contains the Openshift specific deployment configuration for the bpfman-operator.
- `prometheus/`: Contains the prometheus manifests used to deploy Prometheus to a cluster.
At the time of writing this the bpfman-operator is NOT exposing any metrics to prometheus, but this is a future goal.
- - **rbac/**: Contains rbac yamls for getting bpfman and the bpfman-operator up and running on Kubernetes.
- - **bpfman-agent/**: Contains the rbac yamls for the bpfman-agent.
+ - **rbac/**: Contains RBAC yamls for getting bpfman and the bpfman-operator up and running on Kubernetes.
+ - **bpfman-agent/**: Contains the RBAC yamls for the bpfman-agent.
They are automatically generated by kubebuilder via build tags in the bpfman-agent controller code.
- - **bpfman-operator/**: Contains the rbac yamls for the bpfman-operator.
+ - **bpfman-operator/**: Contains the RBAC yamls for the bpfman-operator.
They are automatically generated by kubebuilder via build tags in the bpfman-operator controller code.
- - `samples/`: Contains sample CR definitions that can be deployed by users for each of our supported APIs.
+ - `samples/`: Contains CRD samples that can be deployed by users for each of our supported APIs.
- `scorecard/`: Contains the scorecard manifests used to deploy scorecard to a cluster. At the time of writing
this the bpfman-operator is NOT running any scorecard tests.
- `test/`: Contains the test manifests used to deploy the bpfman-operator to a kind cluster for integration testing.
@@ -185,24 +190,91 @@ follow best practices describe in
See [container-storage-interface/spec/spec.md](https://github.com/container-storage-interface/spec/blob/master/spec.md)
for more details.
-### Generated Files
+### Generated Files and Adding New Program Type
The [operator-sdk framework](https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/#project-layout)
-will generate multiple categories of files (Custom Resource Definitions (CRD), RBAC ClusterRole, Webhook Configuration,
+will generate multiple categories of files (Custom Resource Definitions (CRD), RBAC Role and ClusterRole, Webhook Configuration,
typed client, listeners and informers code, etc).
-If any of the
-[bpfman-operator/apis/v1alpha1/*Program_types.go](https://github.com/bpfman/bpfman/tree/main/bpfman-operator/apis/v1alpha1)
-files are modified, then regenerate these files using:
+When adding a new Program Type or if any of these files are modified, then the auto-generated files must be regenerated:
+
+* [bpfman-operator/apis/v1alpha1/*_types.go](https://github.com/bpfman/bpfman-operator/tree/main/apis/v1alpha1):
+ Contains the K8s CRD api definitions (`*_types.go`) for each program type.
+ When adding a new Program Type, add a file here for the new type.
+* [bpfman-operator/config/crd/kustomization.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/crd/kustomization.yaml):
+ This file specifies the output location for the generated yaml files that define the Custom Resource
+ Definitions (CRDs).
+ This file must be updated when a new CRD needs to be generated.
+* [bpfman-operator/config/crd/patches/](https://github.com/bpfman/bpfman-operator/tree/main/config/crd/patches):
+ There is a `cainjection_in_*programs.yaml` and `webhook_in_*programs.yaml` file for each Program Type
+ in this directory.
+ When adding a new Program Type, add files here for the new type.
+* [bpfman-operator/config/manifests/bases/bpfman-operator.clusterserviceversion.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/manifests/bases/bpfman-operator.clusterserviceversion.yaml):
+ This file has a list of bpfman Custom Resource Definitions.
+ When adding a new Program Type, an entry for the new type must be added to this file.
+* [bpfman-operator/config/samples/bpfman.io_v1alpha1_\*_\*program.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/manifests/bases/bpfman-operator.clusterserviceversion.yaml):
+ Contains a sample of how to deploy each Program Type.
+ When adding a new Program Type, add a file here for the new type.
+* [bpfman-operator/controllers/bpfman-agent/*_program.go](https://github.com/bpfman/bpfman-operator/tree/main/controllers/bpfman-agent):
+ Contains the Program Type specific reconciler for the bpfman-agent.
+ If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated.
+ When adding a new Program Type, add a file here for the new type.
+* [bpfman-operator/controllers/bpfman-agent/common.go](https://github.com/bpfman/bpfman-operator/blob/main/controllers/bpfman-agent/common.go):
+ Contains the common reconciler code for the bpfman-agent.
+ If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated.
+ When adding a new Program Type, `//+kubebuilder:rbac` directives need to be added for the new type.
+* [bpfman-operator/controllers/bpfman-operator/*_program.go](https://github.com/bpfman/bpfman-operator/tree/main/controllers/bpfman-operator):
+ Contains the Program Type specific reconciler for the bpfman-operator.
+ If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated.
+ When adding a new Program Type, add a file here for the new type.
+* [bpfman-operator/controllers/bpfman-operator/common.go](https://github.com/bpfman/bpfman-operator/blob/main/controllers/bpfman-operator/common.go):
+ Contains the common reconciler code for the bpfman-operator.
+ If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated.
+ When adding a new Program Type, `//+kubebuilder:rbac` directives need to be added for the new type.
+
+Then regenerate the generated files using:
```bash
cd bpfman-operator/
make generate
```
-This command will generate all auto-generated code.
There are commands to generate each sub-category if needed.
See `make help` to list all the generate commands.
+This command will generate the following files:
+
+* [bpfman-operator/apis/v1alpha1/zz_generate.register.go](https://github.com/bpfman/bpfman-operator/tree/main/apis/v1alpha1):
+ Contains the auto-generated register methods for all the Program Types.
+* [bpfman-operator/apis/v1alpha1/zz_generated.deepcopy.go](https://github.com/bpfman/bpfman-operator/tree/main/apis/v1alpha1):
+ Contains the deep copy methods for all the Program Types.
+* [bpfman-operator/config/crd/bases/bpfman.io_*programs.yaml](https://github.com/bpfman/bpfman-operator/tree/main/config/crd/bases):
+ Contains the yaml files that the define the Custom Resource Definitions (CRDs).
+* [bpfman-operator/config/rbac/bpfman-agent/role.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/rbac/bpfman-agent/role.yaml):
+ Contains the `Role` and `ClusterRole` definitions for bpfman-agent.
+ Controls the bpfman-agent access rights to each of the Program Type CRDs.
+ Generated from the `//+kubebuilder:rbac` directives in source code.
+* [bpfman-operator/config/rbac/bpfman-operator/role.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/rbac/bpfman-operator/role.yaml):
+ Contains the `Role` and `ClusterRole` definitions for bpfman-operator.
+ Controls the bpfman-operator access rights to each of the Program Type CRDs.
+ Generated from the `//+kubebuilder:rbac` directives in source code.
+* [bpfman-operator/pkg/client/*](https://github.com/bpfman/bpfman-operator/tree/main/pkg/client):
+ Everything under this directory is generated.
+ Contains client Golang code to enable applications to easily integrate with bpfman.
+
+Then regenerate the generated bundle files using (Note: `make bundle` calls `make generate`):
+
+```bash
+cd bpfman-operator/
+make bundle
+```
+
+This command will generate the following files:
+
+* [bpfman-operator/bundle/*](https://github.com/bpfman/bpfman-operator/tree/main/bundle):
+ Contains the bundle manifests and metadata for the operator.
+ This bundle is used to deploy the CRDs in a cluster.
+ More details can be found in the operator-sdk documentation.
+
### Building
To run in Kubernetes, bpfman components need to be containerized.
@@ -224,7 +296,7 @@ make build-images
If the `make build` command is skipped above, the code will be built in the build-images command.
If the `make build` command is run, the built code will be leveraged in this step.
-This command generates the following images:
+This command generates the following local images:
```bash
docker images
@@ -235,6 +307,31 @@ quay.io/bpfman/bpfman-operator latest 4fe444b7abf1 2 minutes ago 141MB
:
```
+When running in KIND (see below), the local images will be loaded into the KIND
+environment.
+There may be times when the image need to be built and pushed to a remote repository
+like quay.io so they can be shared or loaded in a remote cluster.
+The `Makefile` uses the following variables to manage the location of the built images:
+
+* **BPFMAN_IMG:** The bpfman image is not built from the bpfman operator repository, but the
+ bpfman operator yaml files control which image is loaded in the cluster.
+ Use this variable to manage the bpfman image loaded by the bpfman-operator.
+ If not specified, defaults to `quay.io/bpfman/bpfman:latest`.
+* **BPFMAN_AGENT_IMG:** The bpfman agent image.
+ If not specified, defaults to `quay.io/bpfman/bpfman-agent:latest`.
+* **BPFMAN_OPERATOR_IMG:** The bpfman operator image.
+ If not specified, defaults to `quay.io/bpfman/bpfman-operatorman:latest`.
+
+To build the bpfman operator images with custom image locations, use something similar to:
+
+```bash
+cd bpfman-operator/
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman:test \
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \
+BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \
+make build-images
+```
+
## Running Locally in KIND
[Deploying the bpfman-operator](../getting-started/operator-quick-start.md) goes into more detail on ways to
@@ -246,6 +343,13 @@ cd bpfman-operator/
make run-on-kind
```
+> **NOTE:** By default, bpfman-operator deploys bpfman with CSI enabled.
+CSI requires Kubernetes v1.26 due to a PR
+([kubernetes/kubernetes#112597](https://github.com/kubernetes/kubernetes/pull/112597))
+that addresses a gRPC Protocol Error that was seen in the CSI client code and it doesn't appear to have
+been backported.
+It is recommended to install kind v0.20.0 or later.
+
The `make run-on-kind` will run the `make build-images` if the images do not exist or need updating.
Then rebuild and load a fresh build run:
@@ -269,6 +373,239 @@ BPFMAN_IMG=<your/image/url> BPFMAN_AGENT_IMG=<your/image/url> BPFMAN_OPERATOR_IM
See [Kubernetes Operator Tests](https://bpfman.io/main/developer-guide/testing/#kubernetes-operator-tests).
+## Deploy To Existing Cluster
+
+There are several ways to deploy bpfman to an existing Kubernetes cluster.
+The cluster needs to be up and running and specified in ~/.kube/config file.
+
+* **OperatorHub:** bpfman can be installed in a cluster from either the community OperatorHub
+ ([OperatorHub.io](https://operatorhub.io/)) or to an OpenShift Cluster via the OpenShift
+ Console and the builtin Console OperatorHub.
+ This is the recommended method for installing the latest release of bpfman/bpfman-operator.
+
+* **Custom OpenShift Console OperatorHub Bundle:** Custom bpfman/bpfman-operator image can be
+ installed in via OpenShift Console OperatorHub.
+ This is the recommended method when developing in bpfman/bpfman-operator, building custom images,
+ and needing to test from OpenShift Console OperatorHub.
+
+* **Manually with Kustomize:** bpfman can be manually installed to an OpenShift cluster with
+ Kustomize and raw manifests.
+ This is the recommended method when developing in bpfman/bpfman-operator, building custom images,
+ and wanting to test in an OpenShift cluster.
+
+* **Manually with OLM Bundle:** The other option for installing the bpfman-operator is to install
+ it using [OLM bundle](https://www.redhat.com/en/blog/deploying-operators-olm-bundles).
+
+### OperatorHub
+
+When installing the latest release of bpfman/bpfman-operator, bpfman can be installed in a
+cluster from either the community OperatorHub ([OperatorHub.io](https://operatorhub.io/))
+or to an OpenShift Cluster via the OpenShift Console and the builtin Console OperatorHub.
+
+#### OperatorHub.io
+
+To install from the community OperatorHub, go to ([OperatorHub.io](https://operatorhub.io/)) and
+search for bpfman:
+
+
+
+Click on the bpfman Operator, which will take you to the installation screen:
+
+
+
+Click on the `Install` button, which will take you to the installation instructions, which are a set
+of commands to run to install the bpfman Operator:
+
+
+
+#### OperatorHub via OpenShift Console
+
+To install from the OpenShift Console, from within the OpenShift Console, find `OperatorHub`, which
+is under `Operators` on the left hand side of the page.
+Then search for bpfman:
+
+
+
+There should be two options, `Community` and `Red Hat`.
+The `Community` based Operator tracks the releases from this repository.
+The `Red Hat` based Operator is the downstream version from this repository and releases
+with each OpenShift release.
+Click on the operator to be installed:
+
+
+
+This provides the details on the operator.
+Select the desired Version and click the `Install` button.
+
+
+
+This provides similar details on the operator in a popup window.
+Select the desired Version and click the `Install` button.
+This will install the bpfman Operator on the cluster.
+
+### Custom OpenShift Console OperatorHub Bundle
+
+If developing in bpfman/bpfman-operator and a custom image needs to be loaded
+from OpenShift Console OperatorHub, then make the changes to bpfman/bpfman-operator.
+Once the changes compile and are ready to be tested, build and push the container
+images:
+
+```bash
+cd bpfman-operator/
+
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman:test \
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \
+BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \
+make build-images
+
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \
+BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \
+make push-images
+```
+
+Next, a bundle and catalog needs to be built and pushed:
+
+```bash
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman:test \
+BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \
+BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \
+BUNDLE_IMG=quay.io/$QUAY_USER/bpfman-operator-bundle:developement \
+make bundle bundle-build bundle-push
+
+CATALOG_IMG=quay.io/$QUAY_USER/bpfman-operator-catalog:developement \
+make catalog-build catalog-push
+```
+
+Once the bundle and catalog are built, make sure the cluster is up and
+running and specified in ~/.kube/config file.
+Then deploy the catalog:
+
+```bash
+make catalog-deploy
+```
+
+Now the new catalog should show up in the OperatorHub (may have to refresh or restart the search
+if OperatorHub was already up).
+An additional option should be presented, `Bpfman Operator development`.
+This can be now be installed as described above.
+
+
+
+To clean up at a later time, execute:
+
+```bash
+make catalog-undeploy
+```
+
+### Manually with Kustomize
+
+To manually install with Kustomize and raw manifests, execute the following commands. The Openshift cluster needs to be up and running and specified in ~/.kube/config file.
+
+```bash
+cd bpfman-operator/
+make deploy-openshift
+```
+
+To clean up at a later time, run:
+
+```bash
+make undeploy-openshift
+```
+
+### Manually with OLM Bundle
+
+The other option for installing the bpfman-operator is to install it using
+[OLM bundle](https://www.redhat.com/en/blog/deploying-operators-olm-bundles).
+
+First setup the namespace and certificates for the operator with:
+
+```bash
+cd bpfman-operator
+kubectl apply -f ./hack/ocp-scc-hacks.yaml
+```
+
+Then use `operator-sdk` to install the bundle like so:
+
+```bash
+./bin/operator-sdk run bundle quay.io/bpfman/bpfman-operator-bundle:latest --namespace openshift-bpfman
+```
+
+To clean up at a later time, run:
+
+```bash
+./bin/operator-sdk cleanup bpfman-operator
+kubectl delete -f ./hack/ocp-scc-hacks.yaml
+```
+
+## Verify the Installation
+
+Regardless of the deployment method, if the `bpfman-operator` was deployed successfully,
+you will see the `bpfman-daemon` and `bpfman-operator` pods running without errors:
+
+```bash
+kubectl get pods -n bpfman
+NAME READY STATUS RESTARTS AGE
+bpfman-daemon-w24pr 3/3 Running 0 130m
+bpfman-operator-78cf9c44c6-rv7f2 2/2 Running 0 132m
+```
+
+For further verification, load a sample eBPF Program onto the cluster using
+[Deploy an eBPF Program to the cluster](../getting-started/operator-quick-start.md#deploy-an-ebpf-program-to-the-cluster).
+
+## bpfman-agent Profiling
+
+bpfman-agent process use port `6060` for Golang profiling to be able to get the different profiles.
+
+1. Set port-forward rule in a different terminal:
+
+ ```bash
+ kubectl get pods -n bpfman
+ NAME READY STATUS RESTARTS AGE
+ bpfman-daemon-76v57 3/3 Running 0 14m
+ bpfman-operator-7f67bc7c57-ww52z 2/2 Running 0 14m
+
+ kubectl -n bpfman port-forward bpfman-daemon-76v57 6060
+ ```
+
+2. Download the required profiles:
+
+ `curl -o <profile> http://localhost:6060/debug/pprof/<profile>`
+
+ Where <profile> can be:
+
+ | profile | description |
+ |--------------|-------------------------------------------------------------------------------|
+ | allocs | A sampling of all memory allocations |
+ | block | Stack traces that led to blocking on synchronization primitives |
+ | cmdline | The command line invocation of the current program |
+ | goroutine | Stack traces of all current goroutines |
+ | heap | A sampling of memory allocations of live objects. |
+ | | You can specify the gc GET parameter to run GC before taking the heap sample. |
+ | mutex | Stack traces of holders of contended mutexes |
+ | profile | CPU profile. |
+ | | You can specify the duration in the seconds GET parameter. |
+ | threadcreate | Stack traces that led to the creation of new OS threads |
+ | trace | A trace of execution of the current program. |
+ | | You can specify the duration in the seconds GET parameter. |
+
+ Example:
+
+ ```bash
+ curl "http://localhost:6060/debug/pprof/trace?seconds=20" -o trace
+ curl "http://localhost:6060/debug/pprof/profile?duration=20" -o cpu
+ curl "http://localhost:6060/debug/pprof/heap?gc" -o heap
+ curl "http://localhost:6060/debug/pprof/allocs" -o allocs
+ curl "http://localhost:6060/debug/pprof/goroutine" -o goroutine
+ ```
+
+3. Use [go tool pprof](https://go.dev/blog/pprof) to dig into the profiles (go tool trace
+ for the trace profile) or use web interface.
+ For example:
+
+ ```bash
+ go tool pprof -http=:8080 cpu
+ ```
+
## Troubleshooting
### Metrics/Health port issues
diff --git a/docs/getting-started/operator-quick-start.md b/docs/getting-started/operator-quick-start.md
index 1f37acfb7..ae41a2330 100644
--- a/docs/getting-started/operator-quick-start.md
+++ b/docs/getting-started/operator-quick-start.md
@@ -26,7 +26,7 @@ After reviewing the possible make targets it's quick and easy to get bpfman depl
via a [KIND cluster](https://kind.sigs.k8s.io/) with:
```bash
-cd bpfman/bpfman-operator
+cd bpfman-operator
make run-on-kind
```
@@ -40,67 +40,12 @@ make run-on-kind
### Deploy To Openshift Cluster
-First deploy the operator with one of the following two options:
-
-#### 1. Manually with Kustomize
-
-To install manually with Kustomize and raw manifests simply run the following
-commands.
-The Openshift cluster needs to be up and running and specified in `~/.kube/config`
-file.
-
-```bash
-cd bpfman/bpfman-operator
-make deploy-openshift
-```
-
-Which can then be cleaned up at a later time with:
-
-```bash
-make undeploy-openshift
-```
-
-#### 2. Via the OLM bundle
-
-The other option for installing the bpfman-operator is to install it using
-[OLM bundle](https://www.redhat.com/en/blog/deploying-operators-olm-bundles).
-
-First setup the namespace and certificates for the operator with:
-
-```bash
-cd bpfman/bpfman-operator
-oc apply -f ./hack/ocp-scc-hacks.yaml
-```
-
-Then use `operator-sdk` to install the bundle like so:
-
-```bash
-operator-sdk run bundle quay.io/bpfman/bpfman-operator-bundle:latest --namespace openshift-bpfman
-```
-
-Which can then be cleaned up at a later time with:
-
-```bash
-operator-sdk cleanup bpfman-operator
-```
-
-followed by
-
-```bash
-oc delete -f ./hack/ocp-scc-hacks.yaml
-```
-
-## Verify the Installation
-
-Independent of the method used to deploy, if the bpfman-operator came up successfully
-you will see the bpfman-daemon and bpfman-operator pods running without errors:
-
-```bash
-$ kubectl get pods -n bpfman
-NAME READY STATUS RESTARTS AGE
-bpfman-daemon-w24pr 3/3 Running 0 130m
-bpfman-operator-78cf9c44c6-rv7f2 2/2 Running 0 132m
-```
+The recommend way of deploying bpfman to an OpenShift cluster is via the
+OpenShift Console and using Operator Hub.
+This is described in
+[OperatorHub via OpenShift Console](../developer-guide/develop-operator.md#operatorhub-via-openshift-console).
+For other options, see
+[Deploy To Existing Cluster](../developer-guide/develop-operator.md#deploy-to-existing-cluster).
## API Types Overview
@@ -162,7 +107,7 @@ Any of the cluster scoped samples can be applied as is.
To test the deployment simply deploy one of the sample `xdpPrograms`:
```bash
-cd bpfman/bpfman-operator/
+cd bpfman-operator/
kubectl apply -f config/samples/bpfman.io_v1alpha1_xdp_pass_xdpprogram.yaml
```
diff --git a/docs/img/operatorhub/OperatorHub_Community_bpfman.png b/docs/img/operatorhub/OperatorHub_Community_bpfman.png
new file mode 100644
index 000000000..12d947388
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_Community_bpfman.png differ
diff --git a/docs/img/operatorhub/OperatorHub_Community_bpfman_commands.png b/docs/img/operatorhub/OperatorHub_Community_bpfman_commands.png
new file mode 100644
index 000000000..27fc6ac32
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_Community_bpfman_commands.png differ
diff --git a/docs/img/operatorhub/OperatorHub_Community_bpfman_install.png b/docs/img/operatorhub/OperatorHub_Community_bpfman_install.png
new file mode 100644
index 000000000..dbc71f545
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_Community_bpfman_install.png differ
diff --git a/docs/img/operatorhub/OperatorHub_RedHat_SecurityProfileOperator.png b/docs/img/operatorhub/OperatorHub_RedHat_SecurityProfileOperator.png
new file mode 100644
index 000000000..c1af346ca
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_SecurityProfileOperator.png differ
diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman.png
new file mode 100644
index 000000000..ed812b61d
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman.png differ
diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman_details.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_details.png
new file mode 100644
index 000000000..fe0a26b0b
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_details.png differ
diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman_devel.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_devel.png
new file mode 100644
index 000000000..1032acd50
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_devel.png differ
diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman_install.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_install.png
new file mode 100644
index 000000000..cd868d004
Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_install.png differ
diff --git a/examples/config/base/go-xdp-counter/deployment.yaml b/examples/config/base/go-xdp-counter/deployment.yaml
index 6cabe2d2b..c853e41c6 100644
--- a/examples/config/base/go-xdp-counter/deployment.yaml
+++ b/examples/config/base/go-xdp-counter/deployment.yaml
@@ -1,20 +1,15 @@
---
apiVersion: v1
-kind: Namespace
-metadata:
- name: go-xdp-counter
----
-apiVersion: v1
kind: ServiceAccount
metadata:
name: bpfman-app-go-xdp-counter
- namespace: go-xdp-counter
+ namespace: bpfman
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: go-xdp-counter-ds
- namespace: go-xdp-counter
+ namespace: bpfman
labels:
k8s-app: go-xdp-counter
spec: