Fix CR links in docs and standardize

- Small changes to iperf3 CR

CONTRIBUTING.md

@@ -71,7 +71,7 @@ Example `playbook.yml`:
 
 ### Workload triggers
 [CRD](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) holds the definition of the resource.
-The operator triggers roles based on the conditions defined in a CR ([example](resources/crds/ripsaw_v1alpha1_uperf_cr.yaml)) which will influence which roles the
+The operator triggers roles based on the conditions defined in a CR ([example](config/samples/uperf/cr.yaml) which will influence which roles the
 [playbook](playbook.yml) executes.
 Other vars may be defined that can modify the workload run conditions.
 
@@ -154,7 +154,7 @@ Redefine CRD
 ```
 Apply a new CR
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_uperf_cr.yaml
+# kubectl apply -f config/samples/uperf/cr.yaml
 ```
 
 ## CI
@@ -166,7 +166,7 @@ To ensure that adding new a workload will not break other workloads and its
 behavior can be predicted, we've mandated writing tests before PR can be merged.
 
 If a new workload is added, please follow the instructions to add a testcase to
-[test.sh](test,sh):
+[test.sh](test.sh):
 * copy an existing test like [uperf test](tests/test_uperf.sh)
 * Add commands needed to setup the workload specific requirements if any
 * Add a valid cr file to [test_crs](tests/test_crs/) directory for your workload

Makefile

@@ -40,7 +40,7 @@ ARCH ?= $(shell uname -m | sed 's/x86_64/amd64/')
 # Image URL to use all building/pushing image targets
 REGISTRY ?= quay.io
 ORG ?= cloud-bulldozer
-# Get the current branch/tag name
+# Get the current branch name
 # In case this is the master branch, rename it to latest
 VERSION ?= $(shell git describe --tags 2>/dev/null || git rev-parse --abbrev-ref HEAD | sed 's/master/latest/g')
 IMG ?= $(REGISTRY)/$(ORG)/benchmark-operator:$(VERSION)

README.md

@@ -9,13 +9,15 @@ The easiest way to install the operator is through the operator-sdk methods prov
 
 ```bash
 git clone https://github.com/cloud-bulldozer/benchmark-operator
+cd benchmark-operator
 make deploy
 ```
 
 If you wish to build a version of the operator from your local copy of the repo, you can run
 
 ```bash
 git clone https://github.com/cloud-bulldozer/benchmark-operator
+cd benchmark-operator
 make image-build image-push deploy IMG=$YOUR_IMAGE
 ```
 
@@ -49,7 +51,7 @@ helm uninstall benchmark-operator -n benchmark-operator
 | Workload                       | Use                    | ElasticSearch indexing  | Reconciliation usage       | VM support (kubevirt) | Kata Containers | CI Tested |
 | ------------------------------ | ---------------------- | ------------------ | -------------------------- | --------------------- | --------------- | ------------ |
 | [UPerf](docs/uperf.md)         | Network Performance    | Yes                |  Used, default : 3second  | Working                | Working         | Yes |
-| [Iperf3](docs/iperf.md)       | Network Performance     | No                 |  Used, default : 3second  | Not Supported          | Preview         | Yes |
+| [Iperf3](docs/iperf3.md)       | Network Performance     | No                 |  Used, default : 3second  | Not Supported          | Preview         | Yes |
 | [fio](docs/fio_distributed.md) | Storage IO             | Yes                |  Used, default : 3second  | Working                | Working         | Yes |
 | [Sysbench](docs/sysbench.md)   | System Performance     | No                 |  Used, default : 3second  | Not Supported          | Preview         | Yes |
 | [YCSB](docs/ycsb.md)           | Database Performance   | Yes            |  Used, default : 3second  | Not Supported          | Preview         | Yes |

config/manager/kustomization.yaml

@@ -5,6 +5,12 @@ generatorOptions:
   disableNameSuffixHash: true
 
 configMapGenerator:
-- name: manager-config
-  files:
+- files:
   - controller_manager_config.yaml
+  name: manager-config
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+images:
+- name: controller
+  newName: quay.io/cloud-bulldozer/benchmark-operator
+  newTag: latest

config/samples/iperf3/cr.yaml

@@ -12,7 +12,7 @@ spec:
       transmit_type: time
       transmit_value: 60
       omit_start: 0
-      length_buffer: 128K
+#     length_buffer: 128K
       window_size: 64k
       ip_tos: 0
       mss: 900

docs/cyclictest.md

@@ -43,7 +43,8 @@ spec:
 You can run it by:
 
 ```bash
-oc apply -f resources/crds/ripsaw_v1alpha1_cyclictest_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/cyclictest/cr.yaml # if edited the original one
+# kubectl apply -f <path_to_file> # if created a new cr file
 ```
 ## Looking at results
 

docs/elastic.md

@@ -29,7 +29,7 @@ Current supported ES + Prometheus integrated workloads:
 | Workload                       | Status                 |
 | ------------------------------ | ---------------------- |
 | [UPerf](docs/uperf.md)         | Not Supported    |
-| [Iperf3](docs/iperf.md)        | Not Supported    |
+| [Iperf3](docs/iperf3.md)       | Not Supported    |
 | [fio](docs/fio_distributed.md) | Supported        |
 | [Sysbench](docs/sysbench.md)   | Not Supported    |
 | [YCSB](docs/ycsb.md)           | Not Supported    |

docs/fio_distributed.md

@@ -256,7 +256,8 @@ the cache drop by URL.
 **You must deploy this privileged pod in order for the drop caches requests in the workload to function.**
 
 ```bash
-kubectl apply -f config/samples/fio/cr.yaml
+# kubectl apply -f config/samples/fio/cr.yaml # if edited the original one
+# kubectl apply -f <path_to_file> # if created a new cr file
 ```
 
 *Note: If Ceph is in a namespace other than `rook-ceph` you will need to modify the provided YAML accordingly.*
@@ -265,7 +266,7 @@ Since the cache drop pod is deployed with host networking, the pod will take on
 of the node on which it is running. You will need to use this IP address in the CR file as described above.
 
 ```bash
-kubectl get pod -n rook-ceph rook-ceph-osd-cache-drop --template={{.status.podIP}}
+# kubectl get pod -n rook-ceph rook-ceph-osd-cache-drop --template={{.status.podIP}}
 ```
 
 ## Indexing in elasticsearch and visualization through Grafana

docs/flent.md

@@ -233,7 +233,7 @@ To enable Multus in Ripsaw, here is the relevant config.
 Once done creating/editing the resource file, you can run it by:
 
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_flent_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/flent/cr.yaml # if edited the original one
 # kubectl apply -f <path_to_file> # if created a new cr file
 ```
 

docs/fs-drift.md

@@ -9,7 +9,7 @@ tree - see the benchmark documentation for details.  fs-drift requires that a st
 
 ## Running fs-drift Benchmark
 
-Once the operator has been installed following the instructions, one needs to modify the [cr.yaml](../resources/crds/ripsaw_v1alpha1_fs-drift_cr.yaml) to customize workload parameters - the defaults are selected to demonstrate its operation and are not intended to specify a long-duration test.
+Once the operator has been installed following the instructions, one needs to modify the [cr.yaml](../config/samples/fs-drift/cr.yaml) to customize workload parameters - the defaults are selected to demonstrate its operation and are not intended to specify a long-duration test.
 
 The parameters in [cr.yaml](../config/samples/fs-drift/cr.yaml) would look similar to this example:
 
@@ -37,7 +37,7 @@ specified in a YAML input file also.   YAML input style is a little different --
 is omitted, and single dashes are converted to underscores.   So "--parameter-foo bar" becomes "parameter_foo: bar".
 
 Operator CRs apparently also do not allow dashes in key names.  So for the above example, use the 
-syntax "parameter_foo" instead of "--parameter-foo".  See resources/crds/ for an example of fs-drift CR.
+syntax "parameter_foo" instead of "--parameter-foo".  See `config/samples/fs-drift/` for an example of fs-drift CR.
 
 The following fs-drift parameters will be overridden when fs-drift is used in ripsaw - do not specify these parameters yourself!
 
@@ -56,7 +56,8 @@ intended for Kata containers.
 Once done creating/editing the CR file below, one can run it by:
 
 ```bash
-kubectl apply -f resources/crds/ripsaw_v1alpha1_fs-drift_cr.yaml
+# kubectl apply -f config/samples/fs-drift/cr.yaml # if edited the original one
+# kubectl apply -f <path_to_file> # if created a new cr file
 ```
 
 Deploying the above(assuming worker_pods set to 2) would result in

docs/iperf.md → docs/iperf3.md

@@ -19,14 +19,14 @@ spec:
   args:
     pairs: 1
     hostnetwork: false
-    pin: true
-    pin_server: "master-0"
-    pin_client: "master-1"
+    #pin: true
+    #pin_server: "master-0"
+    #pin_client: "master-1"
     port: 5201
     transmit_type: time
     transmit_value: 60
     omit_start: 0
-    length_buffer: 128K
+    #length_buffer: 128K
     window_size: 64k
     ip_tos: 0
     mss: 900
@@ -116,7 +116,7 @@ $ oc adm policy add-scc-to-user privileged -z benchmark-operator
 Once done creating/editing the resource file, you can run it by:
 
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_iperf3_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/iperf3/cr.yaml # if edited the original one
 # kubectl apply -f <path_to_file> # if created a new cr file
 ```
 

docs/oslat.md

@@ -42,7 +42,8 @@ spec:
 You can run it by:
 
 ```bash
-oc apply -f resources/crds/ripsaw_v1alpha1_oslat_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/oslat/cr.yaml # if edited the original one
+# kubectl apply -f <path_to_file> # if created a new cr file
 ```
 ## Looking at results
 

docs/smallfile.md

@@ -3,7 +3,7 @@
 [Smallfile](https://github.com/distributed-system-analysis/smallfile) is a python-based distributed POSIX workload generator which can be used to quickly measure performance for a variety of metadata-intensive workloads across an entire cluster.
 
 ## Running Smallfile Benchmark using Ripsaw
-Once the operator has been installed following the instructions, one needs to modify the clients parameter(which is currently set to 0), to value greater than 0 in  [ripsaw_v1alpha1_smallfile_cr.yaml](../config/samples/smallfile/cr.yaml) to run default "create" the test. Also, in addtion to that, smallfile operator is completely dependent on storageclass and storagesize. Please make sure to double check the parameters in CRD file.
+Once the operator has been installed following the instructions, one needs to modify the clients parameter(which is currently set to 0), to value greater than 0 in [cr.yaml](../config/samples/smallfile/cr.yaml) to run default "create" the test. Also, in addtion to that, smallfile operator is completely dependent on storageclass and storagesize. Please make sure to double check the parameters in CRD file.
 
 ```yaml
 apiVersion: ripsaw.cloudbulldozer.io/v1alpha1
@@ -64,7 +64,7 @@ Smallfile also comes with a variety of configurable options for running tests, f
   the file operation duration down to microsecond resolution.
  * **file_size_distribution** – only supported value today is exponential.
  * **record_size** -- record size in KB, how much data is transferred in a single
-  read or write system call.  If 0 then it is set to the minimum of the file
+  read or write system call. If 0 then it is set to the minimum of the file
   size and 1-MiB record size limit.
  * **files_per_dir** -- maximum number of files contained in any one directory.
  * **dirs_per_dir** -- maximum number of subdirectories contained in any one
@@ -107,7 +107,7 @@ previous runs for example)
 Once done creating/editing the resource file, one can run it by:
 
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_smallfile_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/smallfile/cr.yaml # if edited the original one
 # kubectl apply -f <path_to_file> # if created a new cr file
 ```
 

docs/sysbench.md

@@ -44,7 +44,7 @@ You can find more information at [sysbench documentation](https://github.com/ako
 Once done creating/editing the resource file, you can run it by:
 
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_sysbench_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/sysbench/cr.yaml # if edited the original one
 # kubectl apply -f <path_to_file> # if created a new cr file
 ```
 

docs/uperf.md

@@ -251,7 +251,7 @@ combinations of UPERF data points to exercise datapath performance from many ang
 Once done creating/editing the resource file, you can run it by:
 
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_uperf_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/uperf/cr.yaml # if edited the original one
 # kubectl apply -f <path_to_file> # if created a new cr file
 ```
 

docs/ycsb.md

@@ -71,6 +71,6 @@ so that the ycsb pod can access the API of database.
 Once done creating/editing the resource file, you can run it by:
 
 ```bash
-# kubectl apply -f resources/crds/ripsaw_v1alpha1_ycsb_cr.yaml # if edited the original one
+# kubectl apply -f config/samples/ycsb/cr.yaml # if edited the original one
 # kubectl apply -f <path_to_file> # if created a new cr file
 ```