diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 433facfa99765228af9b753cf88378fc9d939a88..7559bf2824b2d2db24ec4915667a4ba4a0fc073e 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -15,6 +15,28 @@ stages:
variables:
DOCKER_TLS_CERTDIR: "/certs"
+
+# Theodolite Docs
+
+build-docs:
+ stage: build
+ image: ruby:2.7
+ tags:
+ - exec-docker
+ cache:
+ paths:
+ - docs/vendor
+ before_script:
+ - cd docs
+ - gem install bundler
+ - bundle config set --local path 'vendor'
+ - bundle install
+ script: bundle exec jekyll build
+ artifacts:
+ paths:
+ - docs/_site
+
+
# Theodolite Helm Chart
lint-helm:
diff --git a/docs/.gitignore b/docs/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..f40fbd8ba564ea28e0a2501e2921909467b39887
--- /dev/null
+++ b/docs/.gitignore
@@ -0,0 +1,5 @@
+_site
+.sass-cache
+.jekyll-cache
+.jekyll-metadata
+vendor
diff --git a/docs/Gemfile b/docs/Gemfile
new file mode 100644
index 0000000000000000000000000000000000000000..ef3436c16b884aaca76405cbf09fef1a42b7be1e
--- /dev/null
+++ b/docs/Gemfile
@@ -0,0 +1,31 @@
+source "https://rubygems.org"
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+# bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+#gem "jekyll", "~> 4.2.0"
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.5"
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+gem "github-pages", "~> 215", group: :jekyll_plugins
+# If you have any plugins, put them here!
+#group :jekyll_plugins do
+ #gem "jekyll-feed", "~> 0.12"
+#end
+
+# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
+# and associated library.
+platforms :mingw, :x64_mingw, :mswin, :jruby do
+ gem "tzinfo", "~> 1.2"
+ gem "tzinfo-data"
+end
+
+# Performance-booster for watching directories on Windows
+gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
+
diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock
new file mode 100644
index 0000000000000000000000000000000000000000..c02c195db7e5a655feab6e738fb4c4f0ba58af33
--- /dev/null
+++ b/docs/Gemfile.lock
@@ -0,0 +1,276 @@
+GEM
+ remote: https://rubygems.org/
+ specs:
+ activesupport (6.0.4)
+ concurrent-ruby (~> 1.0, >= 1.0.2)
+ i18n (>= 0.7, < 2)
+ minitest (~> 5.1)
+ tzinfo (~> 1.1)
+ zeitwerk (~> 2.2, >= 2.2.2)
+ addressable (2.7.0)
+ public_suffix (>= 2.0.2, < 5.0)
+ coffee-script (2.4.1)
+ coffee-script-source
+ execjs
+ coffee-script-source (1.11.1)
+ colorator (1.1.0)
+ commonmarker (0.17.13)
+ ruby-enum (~> 0.5)
+ concurrent-ruby (1.1.9)
+ dnsruby (1.61.7)
+ simpleidn (~> 0.1)
+ em-websocket (0.5.2)
+ eventmachine (>= 0.12.9)
+ http_parser.rb (~> 0.6.0)
+ ethon (0.14.0)
+ ffi (>= 1.15.0)
+ eventmachine (1.2.7)
+ execjs (2.8.1)
+ faraday (1.4.3)
+ faraday-em_http (~> 1.0)
+ faraday-em_synchrony (~> 1.0)
+ faraday-excon (~> 1.1)
+ faraday-net_http (~> 1.0)
+ faraday-net_http_persistent (~> 1.1)
+ multipart-post (>= 1.2, < 3)
+ ruby2_keywords (>= 0.0.4)
+ faraday-em_http (1.0.0)
+ faraday-em_synchrony (1.0.0)
+ faraday-excon (1.1.0)
+ faraday-net_http (1.0.1)
+ faraday-net_http_persistent (1.1.0)
+ ffi (1.15.3)
+ forwardable-extended (2.6.0)
+ gemoji (3.0.1)
+ github-pages (215)
+ github-pages-health-check (= 1.17.2)
+ jekyll (= 3.9.0)
+ jekyll-avatar (= 0.7.0)
+ jekyll-coffeescript (= 1.1.1)
+ jekyll-commonmark-ghpages (= 0.1.6)
+ jekyll-default-layout (= 0.1.4)
+ jekyll-feed (= 0.15.1)
+ jekyll-gist (= 1.5.0)
+ jekyll-github-metadata (= 2.13.0)
+ jekyll-mentions (= 1.6.0)
+ jekyll-optional-front-matter (= 0.3.2)
+ jekyll-paginate (= 1.1.0)
+ jekyll-readme-index (= 0.3.0)
+ jekyll-redirect-from (= 0.16.0)
+ jekyll-relative-links (= 0.6.1)
+ jekyll-remote-theme (= 0.4.3)
+ jekyll-sass-converter (= 1.5.2)
+ jekyll-seo-tag (= 2.7.1)
+ jekyll-sitemap (= 1.4.0)
+ jekyll-swiss (= 1.0.0)
+ jekyll-theme-architect (= 0.1.1)
+ jekyll-theme-cayman (= 0.1.1)
+ jekyll-theme-dinky (= 0.1.1)
+ jekyll-theme-hacker (= 0.1.2)
+ jekyll-theme-leap-day (= 0.1.1)
+ jekyll-theme-merlot (= 0.1.1)
+ jekyll-theme-midnight (= 0.1.1)
+ jekyll-theme-minimal (= 0.1.1)
+ jekyll-theme-modernist (= 0.1.1)
+ jekyll-theme-primer (= 0.5.4)
+ jekyll-theme-slate (= 0.1.1)
+ jekyll-theme-tactile (= 0.1.1)
+ jekyll-theme-time-machine (= 0.1.1)
+ jekyll-titles-from-headings (= 0.5.3)
+ jemoji (= 0.12.0)
+ kramdown (= 2.3.1)
+ kramdown-parser-gfm (= 1.1.0)
+ liquid (= 4.0.3)
+ mercenary (~> 0.3)
+ minima (= 2.5.1)
+ nokogiri (>= 1.10.4, < 2.0)
+ rouge (= 3.26.0)
+ terminal-table (~> 1.4)
+ github-pages-health-check (1.17.2)
+ addressable (~> 2.3)
+ dnsruby (~> 1.60)
+ octokit (~> 4.0)
+ public_suffix (>= 2.0.2, < 5.0)
+ typhoeus (~> 1.3)
+ html-pipeline (2.14.0)
+ activesupport (>= 2)
+ nokogiri (>= 1.4)
+ http_parser.rb (0.6.0)
+ i18n (0.9.5)
+ concurrent-ruby (~> 1.0)
+ jekyll (3.9.0)
+ addressable (~> 2.4)
+ colorator (~> 1.0)
+ em-websocket (~> 0.5)
+ i18n (~> 0.7)
+ jekyll-sass-converter (~> 1.0)
+ jekyll-watch (~> 2.0)
+ kramdown (>= 1.17, < 3)
+ liquid (~> 4.0)
+ mercenary (~> 0.3.3)
+ pathutil (~> 0.9)
+ rouge (>= 1.7, < 4)
+ safe_yaml (~> 1.0)
+ jekyll-avatar (0.7.0)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-coffeescript (1.1.1)
+ coffee-script (~> 2.2)
+ coffee-script-source (~> 1.11.1)
+ jekyll-commonmark (1.3.1)
+ commonmarker (~> 0.14)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-commonmark-ghpages (0.1.6)
+ commonmarker (~> 0.17.6)
+ jekyll-commonmark (~> 1.2)
+ rouge (>= 2.0, < 4.0)
+ jekyll-default-layout (0.1.4)
+ jekyll (~> 3.0)
+ jekyll-feed (0.15.1)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-gist (1.5.0)
+ octokit (~> 4.2)
+ jekyll-github-metadata (2.13.0)
+ jekyll (>= 3.4, < 5.0)
+ octokit (~> 4.0, != 4.4.0)
+ jekyll-mentions (1.6.0)
+ html-pipeline (~> 2.3)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-optional-front-matter (0.3.2)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-paginate (1.1.0)
+ jekyll-readme-index (0.3.0)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-redirect-from (0.16.0)
+ jekyll (>= 3.3, < 5.0)
+ jekyll-relative-links (0.6.1)
+ jekyll (>= 3.3, < 5.0)
+ jekyll-remote-theme (0.4.3)
+ addressable (~> 2.0)
+ jekyll (>= 3.5, < 5.0)
+ jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
+ rubyzip (>= 1.3.0, < 3.0)
+ jekyll-sass-converter (1.5.2)
+ sass (~> 3.4)
+ jekyll-seo-tag (2.7.1)
+ jekyll (>= 3.8, < 5.0)
+ jekyll-sitemap (1.4.0)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-swiss (1.0.0)
+ jekyll-theme-architect (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-cayman (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-dinky (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-hacker (0.1.2)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-leap-day (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-merlot (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-midnight (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-minimal (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-modernist (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-primer (0.5.4)
+ jekyll (> 3.5, < 5.0)
+ jekyll-github-metadata (~> 2.9)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-slate (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-tactile (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-time-machine (0.1.1)
+ jekyll (~> 3.5)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-titles-from-headings (0.5.3)
+ jekyll (>= 3.3, < 5.0)
+ jekyll-watch (2.2.1)
+ listen (~> 3.0)
+ jemoji (0.12.0)
+ gemoji (~> 3.0)
+ html-pipeline (~> 2.2)
+ jekyll (>= 3.0, < 5.0)
+ kramdown (2.3.1)
+ rexml
+ kramdown-parser-gfm (1.1.0)
+ kramdown (~> 2.0)
+ liquid (4.0.3)
+ listen (3.5.1)
+ rb-fsevent (~> 0.10, >= 0.10.3)
+ rb-inotify (~> 0.9, >= 0.9.10)
+ mercenary (0.3.6)
+ minima (2.5.1)
+ jekyll (>= 3.5, < 5.0)
+ jekyll-feed (~> 0.9)
+ jekyll-seo-tag (~> 2.1)
+ minitest (5.14.4)
+ multipart-post (2.1.1)
+ nokogiri (1.11.7-x86_64-linux)
+ racc (~> 1.4)
+ octokit (4.21.0)
+ faraday (>= 0.9)
+ sawyer (~> 0.8.0, >= 0.5.3)
+ pathutil (0.16.2)
+ forwardable-extended (~> 2.6)
+ public_suffix (4.0.6)
+ racc (1.5.2)
+ rb-fsevent (0.11.0)
+ rb-inotify (0.10.1)
+ ffi (~> 1.0)
+ rexml (3.2.5)
+ rouge (3.26.0)
+ ruby-enum (0.9.0)
+ i18n
+ ruby2_keywords (0.0.4)
+ rubyzip (2.3.0)
+ safe_yaml (1.0.5)
+ sass (3.7.4)
+ sass-listen (~> 4.0.0)
+ sass-listen (4.0.0)
+ rb-fsevent (~> 0.9, >= 0.9.4)
+ rb-inotify (~> 0.9, >= 0.9.7)
+ sawyer (0.8.2)
+ addressable (>= 2.3.5)
+ faraday (> 0.8, < 2.0)
+ simpleidn (0.2.1)
+ unf (~> 0.1.4)
+ terminal-table (1.8.0)
+ unicode-display_width (~> 1.1, >= 1.1.1)
+ thread_safe (0.3.6)
+ typhoeus (1.4.0)
+ ethon (>= 0.9.0)
+ tzinfo (1.2.9)
+ thread_safe (~> 0.1)
+ unf (0.1.4)
+ unf_ext
+ unf_ext (0.0.7.7)
+ unicode-display_width (1.7.0)
+ zeitwerk (2.4.2)
+
+PLATFORMS
+ x86_64-linux
+ x86_64-linux-musl
+
+DEPENDENCIES
+ github-pages (~> 215)
+ minima (~> 2.5)
+ tzinfo (~> 1.2)
+ tzinfo-data
+ wdm (~> 0.1.1)
+
+BUNDLED WITH
+ 2.2.21
diff --git a/docs/README.md b/docs/README.md
index 4fd13bdfc157efe8b3491695bb83972f96a82c5d..a1e43024a89c05a56aec2410b6c130dde0645ba0 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,6 +1,7 @@
---
title: Theodolite
nav_order: 1
+nav_exclude: true
permalink: /
---
diff --git a/docs/_config.yml b/docs/_config.yml
index b0f0a13c22083b21a7c90ceaed44b846ffe55550..a4997a99b26fcdb24b08a892a64fefa14bf69081 100644
--- a/docs/_config.yml
+++ b/docs/_config.yml
@@ -1,6 +1,15 @@
title: "Theodolite"
+description: >-
+ Theodolite is a framework for benchmarking the horizontal and vertical
+ scalability of stream processing engines.
+
remote_theme: pmarsceill/just-the-docs
#color_scheme: "dark"
aux_links:
"Theodolite on GitHub":
- - "//github.com/cau-se/theodolite"
\ No newline at end of file
+ - "//github.com/cau-se/theodolite"
+
+exclude:
+ - Gemfile
+ - Gemfile.lock
+ - vendor
diff --git a/docs/benchmarks-and-executions.md b/docs/benchmarks-and-executions.md
new file mode 100644
index 0000000000000000000000000000000000000000..3e17e35307deea6b906d774933c6c5ffe8b6ee44
--- /dev/null
+++ b/docs/benchmarks-and-executions.md
@@ -0,0 +1,43 @@
+---
+title: Benchmarks and Executions
+has_children: false
+nav_order: 2
+---
+
+# Benchmarks and Executions
+
+In Theodolite, we distinguish between the static description of a scalability benchmark and its execution.
+
+## Benchmarks
+
+Benchmarks define what should be executed in scalability experiments. They
+consists of system under test (SUT) and an associated load generator, where
+both SUT and load generator are represented as sets of Kubernetes resources
+such Pods, Services, or ConfigMaps.
+Additionally, benchmarks define one or more load and resource types, scalability
+can be evaluated for.
+
+[TODO]: # (Link to metrics)
+
+Benchmarks are portable, that is they can be provided by standardization
+organizations, researchers, etc. and installed by other researchers,
+engineers, etc.
+They do not have a life-cycle. Instead, to run a benchmark, an execution of a
+benchmark is created and passed to Theodolite.
+
+## Execution
+
+An execution represents a one-time execution of a benchmark with a
+specific configuration. Hence, an execution refers to a benchmark and one of
+the load and resource types defined by that benchmark. Additionally, executions
+allow to alter the SUT or the load generator to evaluate regarding specific
+configurations.
+
+Executions also describe details regarding the scalability measurement method,
+such as for long experiment should be performed or how often they should be
+repeated.
+
+In contrast to benchmarks, execution have a life-cycle. They can be planned,
+executed, or aborted. Each execution of a benchmark is represented by an
+individual entity. This supports repeatability as executions can be archived
+and shared.
diff --git a/docs/installation.md b/docs/installation.md
new file mode 100644
index 0000000000000000000000000000000000000000..e4381fbfb6646bc13021c78cdc13f8c8a6c28500
--- /dev/null
+++ b/docs/installation.md
@@ -0,0 +1,67 @@
+---
+title: Installation
+has_children: false
+nav_order: 3
+---
+
+# Installing Theodolite
+
+The easiest option to install Theodolite is using [Helm](https://helm.sh).
+To install Theodolite with all its dependencies run:
+
+```sh
+helm repo add theodolite https://cau-se.github.io/theodolite
+helm repo update
+helm install theodolite theodolite/theodolite
+```
+
+This installs Theodolite in operator mode. Operator mode is the easiest to be used, but requires some permissions in the installation. If those cannot be granted, Theodolite can also be installed for standalone mode.
+
+
+## Installation Options
+
+As usual, the installation via Helm can be configured by passing a values YAML file:
+
+```
+helm install theodolite theodolite/theodolite --values <your-config.yaml>
+```
+
+For this purpose the [default values file]() can serve as a template for your custom configuration.
+
+### Operator mode
+
+The Theodolite operator allows to run and manage benchmarks through the Kubernetes API. It is installed by setting `operator.enabled` to `true`. In addition to Theodolite's dependencies, this will deploy all resources that are required for the operator as well as the CRDs, users will interact with.
+
+**TODO:** link
+
+### Standalone mode
+
+For running Theodolite in standalone mode, it is sufficient to disable the operator by setting `operator.enabled` to `false`. With this setting, only Theodolite's dependencies as well as resources to get the necessary permissions are installed.
+
+### Random Scheduler
+
+Installation of the random scheduler can be enabled and via `randomScheduler.enabled`. Please note that the random scheduler is neither required in operator mode nor in standalone mode. However, it has to be installed if benchmark executions should use random scheduling.
+
+**TODO:** link
+
+### Multiple installations in the same cluster
+
+Multiple Theodolite installations in the same namespace are currently not fully tested.
+In cases, where you need to install multiple Theodolite instances, it's best to use dedicated namespaces **and** different release names.
+
+*Note that for meaningful results, usually only one benchmark should be executed at a time.*
+
+## Installation Hints
+
+### Installation with a release name other than `theodolite`
+
+When using another release name than `theodolite`, make sure to adjust the Kafka Lag Exporter configuration of you `values.yaml` accordingly:
+
+```yaml
+kafka-lag-exporter:
+ clusters:
+ - name: "<your-release-name>-cp-kafka"
+ bootstrapBrokers: "<your-release-name>-cp-kafka:9092"
+```
+
+This seems unfortunately to be necessary as Helm does not let us inject values into dependency charts.
diff --git a/docs/release-process.md b/docs/release-process.md
index 981306b0762e43eacb29a434cc1e505593548fce..28456f44291a2938974e53a6be5254882215d237 100644
--- a/docs/release-process.md
+++ b/docs/release-process.md
@@ -1,7 +1,7 @@
---
title: Release Process
has_children: false
-nav_order: 2
+nav_order: 5
---
# Release Process
@@ -35,7 +35,7 @@ again be merged into master.
7. Tag this commit `v0.3.1` (can be done via GitLab). The corresponding Docker images will be uploaded.
-8. Create *releases* on GitLab and GitHub. Upload the generated Helm package to these releases.
+8. Create *releases* on GitLab and GitHub. Upload the generated Helm package to these releases via the UIs of GitLab and GitHub.
9. Switch to the `master` branch.
diff --git a/docs/running-benchmarks.md b/docs/running-benchmarks.md
new file mode 100644
index 0000000000000000000000000000000000000000..3cb8e30aa916352d1dcfeb62701c5df660cb9026
--- /dev/null
+++ b/docs/running-benchmarks.md
@@ -0,0 +1,111 @@
+---
+title: Running Benchmarks
+has_children: false
+nav_order: 4
+---
+
+# Running Scalability Benchmarks
+
+There are two options to run scalability benchmarks with Theodolite:
+
+1. The [Theodolite Operator](#running-benchmarks-with-the-theodolite-operator) is a long-running service in your cluster, which accepts submitted benchmarks and executes them.
+2. In [standalone mode](#running-benchmarks-in-standalone-mode), Theodolite is started as a Kubernetes Job and only runs for the duration of one benchmark execution.
+
+While the operator is a bit more complex to install then the standalone mode,
+it makes it way easier to manage benchmarks and their executions. In
+particular, it allows to submit a set of experiments, which are then executed
+automatically one after another.
+**Therefore, running benchmarks with the operator is recommended.**
+
+
+## Running Benchmarks with the Theodolite Operator
+
+The general process for running Theodolite benchmarks in operator mode is as follows:
+
+1. Create and deploy a new `Benchmark` resource or deploy one of the already existing ones.
+2. Define your benchmark execution as an `Execution` resource and deploy it.
+
+### 1. Creating a benchmark
+
+Benchmarks are defined as resources of our custom resource definition
+`Benchmark`. You can either create a new `Benchmark` for your custom benchmark
+or system under test or deploy one of the existing benchmarks, which can be
+found in [`theodolite-benchmarks/definitions`](theodolite-benchmarks/definitions). **TODO link**
+
+Suppose your `Benchmark` resource is stored in `example-benchmark.yaml`, you
+can deploy it by running:
+
+```sh
+kubectl apply -f example-benchmark.yaml
+```
+
+To see the list of all deployed benchmarks run:
+
+```sh
+kubectl get benchmarks
+```
+
+Additionally you need to make all your benchmark's Kubernetes resources available to the operator.
+
+**TODO benchmark resources**
+
+Once your benchmark is deployed, it is ready to be executed.
+
+### 2. Creating an execution
+
+To execute a benchmark, you need to describe this execution by creating an `Execution` resource.
+
+**TODO: details execution**
+
+Suppose your `Execution` resource is stored in `example-execution.yaml`, you
+can deploy it by running:
+
+```sh
+kubectl apply -f example-execution.yaml
+```
+
+To see the list of all deployed benchmarks run:
+
+```sh
+kubectl get executions
+```
+
+The `STATUS` field will tell you whether a benchmark execution has been
+started, finished or failed due to some error. The `DURATION` field tells you
+for how long that execution is running (so far). Similar to a Kubernetes Job,
+an `Execution` is not automatically deleted once it is finished. This makes it
+easier to keep track of all the benchmark executions and to organize benchmark
+results.
+
+
+## Running Benchmarks in Standalone Mode
+
+The general process for running Theodolite benchmarks in standalone mode is as follows:
+
+1. Create a benchmark by writing a YAML file or select one of the already existing ones and create a ConfigMap from it.
+2. Define your benchmark execution as a YAML file and create a ConfigMap from it. We provide a template for this.
+3. Create a Theodolite Job from our template and mount your benchmark and benchmark execution with it.
+
+### 1. Creating a benchmark
+
+Creating a benchmark in standalone mode is similar to operator mode. However,
+instead of defining a benchmark as `Benchmark` resource, it is defined as a
+benchmark YAML file. Such a file deviates in the following points from a
+`Benchmark` resource:
+
+* The fields `apiVersion`, `kind` and `metadata` should be removed.
+* The benchmark's name (`metadata.name` in `Benchmark` resources) must be defined by the top-level field `name`.
+* Everything that is defined in `spec` has to be moved to the top-level.
+
+**TODO: example**
+
+**TODO: Create a ConfigMap containing the benchmark YAML files as well as all Kubernetes resources for that benchmark + deploy**
+
+### 2. Creating an execution
+
+**TODO: see above**
+
+
+### 3. Create a Theodolite Job
+
+**TODO example**
\ No newline at end of file