Update documentation (#155)

- introduce the new separate-releases-for-operater-and-chart approach
- fix some wording
- remove c&p error from `machine-operator`
- remove spaces at the end of the lines (hate those!)

docs/development/contribution.md

@@ -1,34 +1,34 @@
 # Contributors Guide
 
-## Contributing 
+## Contributing
 
 The Gardener on Metal project uses Github to manage reviews of pull requests.
 
 * If you are looking to make your first contribution, follow [Steps to Contribute](#steps-to-contribute)
 
 * If you have a trivial fix or improvement, go ahead and create a pull request and
-address (with @...) a suitable maintainer of this repository 
-(see [CODEOWNERS](https://raw.githubusercontent.com/onmetal/meeting-operator/master/CODEOWNERS) 
+address (with @...) a suitable maintainer of this repository
+(see [CODEOWNERS](https://raw.githubusercontent.com/onmetal/meeting-operator/master/CODEOWNERS)
 of this repository) in the description of the pull request.
 
-* If you plan to do something more involved, first discuss your ideas by creating an 
-[issue](https://github.com/onmetal/meeting-operator/issues) for this repository. This will avoid unnecessary work and surely give you 
+* If you plan to do something more involved, first discuss your ideas by creating an
+[issue](https://github.com/onmetal/meeting-operator/issues) for this repository. This will avoid unnecessary work and surely give you
 and us a good deal of inspiration.
 
-!!! note 
+!!! note
     Please follow these style guidelines to have your contribution considered by the maintainers:
     Coding style guidelines [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments),
     Formatting and style section of Peter Bourgon’s [Go: Best Practices for Production Environments](http://peter.bourgon.org/go-in-production/#formatting-and-style).
 
 ## Steps to Contribute
 
-Do you want to work on an issue?  You are welcome to claim an existing one by commenting on it in GitHub. 
+Do you want to work on an issue?  You are welcome to claim an existing one by commenting on it in GitHub.
 
 !!! note
-    Perform a cursory search to see if the issue has already been taken by someone else. 
+    Perform a cursory search to see if the issue has already been taken by someone else.
     This will prevent misunderstanding and duplication of  effort from contributors on the same issue.
 
-If you have questions about one of the issues please comment on them and one of the 
+If you have questions about one of the issues please comment on them and one of the
 maintainers will clarify it.
 
 We kindly ask you to follow the [Pull Request Checklist](#pull-request-checklist) to ensure reviews can happen accordingly.
@@ -53,8 +53,8 @@ The following rules govern documentation contributions:
 
 ## Developer Certificate of Origin
 
-Due to legal reasons, contributors will be asked to accept a Developer Certificate of Origin (DCO) before they submit 
-the first pull request to the Gardener on Metal project, this happens in an automated fashion during the submission 
+Due to legal reasons, contributors will be asked to accept a Developer Certificate of Origin (DCO) before they submit
+the first pull request to the Gardener on Metal project, this happens in an automated fashion during the submission
 process. We use [the standard DCO text of the Linux Foundation](https://developercertificate.org/).
 
 ## Pull Request Checklist
@@ -66,8 +66,8 @@ git clone [email protected]:YOUR_GITHUB_USER/meeting-operator.git
 cd meeting-operator
 ```
 
-* Create a branch from the `master`  using 'git checkout' command. 
-!!! note 
+* Create a branch from the `master`  using 'git checkout' command.
+!!! note
     If needed, rebase to the current `master` branch before submitting  your pull request. If it doesn't merge properly
     with `master` you may be asked to rebase your changes.
 
@@ -78,10 +78,10 @@ cd meeting-operator
     git rebase upstream/main
     ```
 
-* Commits should be as small as possible, while ensuring that each commit is correct independently 
+* Commits should be as small as possible, while ensuring that each commit is correct independently
 (i.e. each commit should compile and pass tests).
 
-*  Create your patch and test your changes  before you commit them. Automated test by unit / integration tests are preferred. 
+*  Create your patch and test your changes  before you commit them. Automated test by unit / integration tests are preferred.
 If tested manually, provide information about the test scope in the PR description. Now you can commit
 your changes to your feature branch and push it to your fork.
 
@@ -94,10 +94,10 @@ git push origin my_feature
 !!! note
     Alternatively you can amend your commit before pushing if you forgot something by using `git commit --amend`
 
-* Create _Work In Progress [WIP]_ pull requests only if you need a clarification or an explicit review before you can 
+* Create _Work In Progress [WIP]_ pull requests only if you need a clarification or an explicit review before you can
 continue your work item.
 
-* If your patch is not getting reviewed, or you need a specific person to review it, you can @-reply a reviewer asking 
+* If your patch is not getting reviewed, or you need a specific person to review it, you can @-reply a reviewer asking
 for a review in the pull request or a comment.
 
 * Post review:
@@ -108,7 +108,7 @@ for a review in the pull request or a comment.
 
 ## Issues and Planning
 
-We use GitHub issues to track bugs and enhancement requests. Please provide as much context as possible when you open  an issue. The information you provide must be comprehensive enough to understand, reproduce the behavior and find related reports of  that issue for the assignee. 
+We use GitHub issues to track bugs and enhancement requests. Please provide as much context as possible when you open  an issue. The information you provide must be comprehensive enough to understand, reproduce the behavior and find related reports of  that issue for the assignee.
 Therefore, contributors may use but aren't restricted to the issue template provided by the Gardener on Metal maintainers.
 
 Issues and pull requests are tracked in the [backlog](https://github.com/onmetal/meeting-operator/projects/1) for this project.

docs/development/documentation.md

@@ -1,6 +1,6 @@
 # Documentation Setup
 
-The documentation of the [machine-operator](https://github.com/onmetal/machine-operator) project is written primarily using Markdown.
+The documentation of the [meeting-operator](https://github.com/onmetal/meeting-operator) project is written primarily using Markdown.
 All documentation related content can be found in the `/docs` folder. New content also should be added there.
 [MkDocs](https://www.mkdocs.org/) and [MkDocs Material](https://squidfunk.github.io/mkdocs-material/) are then used to render the contents of the `/docs` folder to have a more user-friendly experience when browsing the projects' documentation.
 
@@ -15,11 +15,11 @@ Instead, in order to introduce breaking changes to the API, a new API version sh
 First, move the existing controller to the different file, as generator will try to put a new controller
 into the same location, e.g.
 
-    mv controllers/machine/controller.go controllers/machine/v1alpha1_controller.go
+    mv internal/jitsi/web/controller.go internal/jitsi/web/v1beta1_controller.go
 
 After that, add a new API version:
 
-    operator-sdk create api --version v1alpha2 --kind Machine --resource --controller
+    operator-sdk create api --version v1beta1 --kind Web --resource --controller
 
 Do modifications in a new CR, add a new controller to `main.go`.
 
@@ -51,7 +51,7 @@ patchesJson6902:
       version: v1
       group: apiextensions.k8s.io
       kind: CustomResourceDefinition
-      name: machines.machine.onmetal.de
+      name: webs.jitsi.meeting.ko
     path: crd_patch.yaml
 ```
 
@@ -65,5 +65,6 @@ This includes:
 
 ## Versioning
 
-We use [SemVer](http://semver.org/) for versioning. For the versions available, see the [link to tags on this repository](https://github.com/onmetal/machine-operator/tags).
+For the operator we use [SemVer](http://semver.org/) for versioning. For the versions available, see the [link to tags on this repository](https://github.com/onmetal/meeting-operator/tags).
 
+The helm chart versioning follows its own name and numbering scheme, e.g. `meeting-chart-v0.20.1`.

docs/development/install.md

@@ -12,7 +12,7 @@ Following tools are required to work on that package.
 - [operator framework](https://operatorframework.io/) - framework to maintain project structure
 - [helm](https://helm.sh/) - to work with helm charts
 
-If you have to build Docker images on your host, 
+If you have to build Docker images on your host,
 you also need to have [Docker](https://www.docker.com/) or its alternative installed.
 
 ### Prepare environment
@@ -45,20 +45,20 @@ kubectl create -f config/samples/jitsi-config.yaml
 ## Install
 You can use helm for deploy meeting-operator in the cluster.
 ```
-helm install meeting-operator ./deploy/helm/meeting-operator
+helm install meeting-operator ./deploy/helm/meeting-chart
 ```
 or
 ```
 helm repo add onmetal https://onmetal.github.io/meeting-operator/
-helm install meeting-operator onmetal/meeting-operator
+helm install meeting-operator onmetal/meeting-chart
 ```
 ### Use the published chart
 
 Add this to your `Chart.yaml`
 ```yaml
 dependencies:
-  - name: meeting-operator
-    version: '0.11.1'
+  - name: meeting-chart
+    version: '0.20.1'
     repository: 'https://onmetal.github.io/meeting-operator'
 ```
 
@@ -77,19 +77,19 @@ kubectl apply -f config/crd/bases/*
 kubectl apply -f config/samples/_v1alpha2_etherpad.yaml
 kubectl apply -f config/samples/_v1alpha2_whiteboard.yaml
 
-### Install jitsi components. 
-kubectl apply -f config/samples/_v1beta1_jitsi_jibri.yaml 
-kubectl apply -f config/samples/_v1beta1_jitsi_jicofo.yaml 
-kubectl apply -fconfig/samples/_v1beta1_jitsi_jigasi.yaml 
-kubectl apply -f config/samples/_v1beta1_jitsi_jvb.yaml 
-kubectl apply -fconfig/samples/_v1beta1_jitsi_prosody.yaml 
+### Install jitsi components.
+kubectl apply -f config/samples/_v1beta1_jitsi_jibri.yaml
+kubectl apply -f config/samples/_v1beta1_jitsi_jicofo.yaml
+kubectl apply -fconfig/samples/_v1beta1_jitsi_jigasi.yaml
+kubectl apply -f config/samples/_v1beta1_jitsi_jvb.yaml
+kubectl apply -fconfig/samples/_v1beta1_jitsi_prosody.yaml
 kubectl apply -fconfig/samples/_v1beta1_jitsi_web.yaml
 ```
 
 If you need to change default values, you should check values.yml
 
 ### Examples
-Folder ``` config/samples``` contain crds, ingress, config examples. It's enough to 
+Folder ``` config/samples``` contain crds, ingress, config examples. It's enough to
 start up with jitsi.
 ```
  ll config/samples
@@ -110,8 +110,16 @@ telegraf-cm.yaml
 
 ### Release Guide
 
-1. Make you Changes
-2. Edit the [`Chart.yml`](/deploy/helm/meeting-operator/Chart.yaml) and update the `version` and `appVersion` accordingly. 
-3. Commit and push (to master, e.g. by merging the PR)
-4. The automated Helm release will create a tag with the specified version
-5. After the Tag is pushed the Docker Release will create the Images specified by the tag. 
+- meeting operator
+1. Make your changes to the operator in a feature branch
+2. Create, review, test and merge the PR
+3. Review the automatically created draft release, release notes are generated automatically from the PRs summary
+4. Publish the draft release
+5. A repository tag (e.g. `meeting-operator-v0.50.0`) will be created
+6. Based on the tag above, a docker image will be built, tagged and pushed. The tag will drop the `meeting-operator-v`-prefix, so the docker image will be called `meeting-operator:0.50.0`
+
+- helm chart
+1. Make your changes to the chart
+2. Edit the [`Chart.yml`](/deploy/helm/meeting-chart/Chart.yaml). The `version` must always be incremented, the `appVersion` must match a valid meeting operator version
+3. Commit and push to default branch, e.g. by merging a PR
+4. The automated helm release will create a tag with the specified helm chart version, e.g. `meeting-chart-v0.20.1`

docs/jvb-autoscaler.md

@@ -1,6 +1,6 @@
 Resource name could be:
 1. jitsi_conference - Metrics based on active JVB conference count for 15m.
-2. jitsi_participants - Metrics based on active JVB participants count for 15m. 
+2. jitsi_participants - Metrics based on active JVB participants count for 15m.
 3. cpu - Metrics based on "Container_Cpu_Usage" (not working with influx right now).
 
 Prometheus example:
@@ -48,4 +48,4 @@ spec:
 For InfluxDB, you can set up next fields in annotations:
 1. jas.influxdb/token = InfluxDB auth token. Field is being required.
 2. jas.influxdb/org = InfluxDB organization name. If field not provided, then it would be equal to "influxdata".
-3. jas.influxdb/bucket = InfluxDB bucket with jitsi metrics. If field not provided, then it would be equal to "jitsi".
+3. jas.influxdb/bucket = InfluxDB bucket with jitsi metrics. If field not provided, then it would be equal to "jitsi".

docs/jvb-custom-sip-configuration.md

@@ -6,12 +6,12 @@ By default, JVB docker container has this sip configuration:
 	{{ end }}
 
 That's mean we can't configure anything except "HARVESTER ADDRESS" for example:
-```	org.jitsi.videobridge.ENABLE_REST_SHUTDOWN=true // enabled by default in operator``` 
+```	org.jitsi.videobridge.ENABLE_REST_SHUTDOWN=true // enabled by default in operator```
 
-But now we can simply set up additional configuration via "custom_sip" 
+But now we can simply set up additional configuration via "custom_sip"
 field in Jitsi Custom Resource.
 For instance:
-```    
+```
     custom_sip:
       - org.jitsi.videobridge.ENABLE_STATISTICS=true
-```
+```