Update docs to Helm 3+ syntax and use proper markdown code blocks

README.md

@@ -21,9 +21,10 @@ Just push to Git and Flux does the rest.
 
 Add the Rucio Helm repository to your local Helm installation then you can install the Rucio server like so.
 
-
-    $ helm repo add rucio https://rucio.github.io/helm-charts
-    $ helm install rucio/rucio-server
+```sh
+helm repo add rucio https://rucio.github.io/helm-charts
+helm install my-release rucio/rucio-server
+```
 
 ## Chart Versioning
 

charts/rucio-daemons/Chart.yaml

@@ -1,5 +1,5 @@
 name: rucio-daemons
-version: 38.0.3
+version: 38.0.4
 apiVersion: v1
 description: A Helm chart to deploy daemons for Rucio
 keywords:

charts/rucio-daemons/README.md

@@ -8,8 +8,10 @@ Rucio is a software framework that provides functionality to organize, manage, a
 
 Add the Rucio Helm repository to your local Helm installation and install it using:
 
-    $ helm repo add rucio https://rucio.github.io/helm-charts
-    $ helm install rucio/rucio-daemons
+  ```sh
+  helm repo add rucio https://rucio.github.io/helm-charts
+  helm install my-release rucio/rucio-daemons
+  ```
 
 ## Introduction
 
@@ -19,32 +21,36 @@ This chart bootstraps a Rucio server deployment and service on a Kubernetes clus
 
 This chart can be used to install Rucio daemons. Not all of the possible daemons are necessary to run a instance of Rucio. Some daemons are optional. By default no daemon is activated and they have to be explicitly started. A simple daemon instance with one judge-cleaner daemon can be started like this:
 
-    $ helm install \
-      --name my-release \
-      --set judgeCleanerCount=1 \
-      rucio/rucio-daemons
+```sh
+helm install my-release rucio/rucio-daemons \
+  --set judgeCleanerCount=1
+```
 
 This command will start 1 judge-cleaner using an un-initialised SQLite database. To fully use this chart an already bootstraped database is necessary. The daemons can then be configured to use the DB.
 
 To install the chart so that is will connected to a MySQL DB running at `mysql.db` with the user `rucio` and password `rucio`:
 
-    $ helm install \
-      --name my-release \
-      --set judgeCleanerCount=1 \
-      --set config.database.default="mysql://rucio:rucio@mysql.db/rucio"
-      rucio/rucio-daemons
+```sh
+helm install my-release rucio/rucio-daemons \
+  --set judgeCleanerCount=1 \
+  --set config.database.default="mysql://rucio:rucio@mysql.db/rucio"
+```
 
 ## Configuration
 
 The default configuration values for this chart are listed in `values.yaml` our you can get them with:
 
-    $ helm inspect values rucio/rucio-daemons
+  ```sh
+  helm show values rucio/rucio-daemons
+  ```
 
 Specify each parameter using the `--set key=value[,key=value]` argument to `helm install` as shown before.
 
 Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,
 
-    $ helm install --name my-release -f values.yaml rucio/rucio-daemons
+```sh
+helm install my-release rucio/rucio-daemons -f values.yaml
+```
 
 ## Certificates
 
@@ -54,18 +60,20 @@ Some of the daemons require certificates and CAs to work. They expect specific s
 
 The conveyor needs a delegated X509 user proxy and the necessary CA so that it can submit jobs to FTS. For the CA you have to add a `<releasename>-rucio-ca-bundle` secret. For the user proxy a cronjob can be setup to either generate it from a long proxy or directly delegate the user proxy to FTS. The cronjob uses the [fts-cron](https://github.com/rucio/containers/tree/master/fts-cron) container which expects different input secrets and has a different behaviour depending on the selected VO. When enabled, the cronjob runs once upon installation and then every 6 hours. An example configuration looks like this:
 
-    ftsRenewal:
-      enabled: 1
-      schedule: "12 */6 * * *"
-      image:
-        repository: rucio/fts-cron
-        tag: latest
-        pullPolicy: Always
-      servers: "https://fts3-devel.cern.ch:8446,https://fts3-pilot.cern.ch:8446"
-      script: default
-      vos:
-        - vo: "cms"
-          voms: "cms:/cms/Role=production"
+```yaml
+ftsRenewal:
+  enabled: 1
+  schedule: "12 */6 * * *"
+  image:
+    repository: rucio/fts-cron
+    tag: latest
+    pullPolicy: Always
+  servers: "https://fts3-devel.cern.ch:8446,https://fts3-pilot.cern.ch:8446"
+  script: default
+  vos:
+    - vo: "cms"
+      voms: "cms:/cms/Role=production"
+```
 
 Please check directly the scripts in the [fts-cron](https://github.com/rucio/containers/tree/master/fts-cron)
 container to see their required input. For example, the "atlas" script requires
@@ -74,19 +82,21 @@ location. And it will be used to generate a short proxy into the kubernetes
 secret with the name given in the `RUCIO_FTS_SECRETS` env variable. 
 The configuration will be like that:
 
-      script: atlas
-      vos:
-        - vo: "atlas"
-          voms: "atlas:/atlas/Role=production"
-        secretMounts:
-          - secretFullName: release-longproxy
-            mountPath: /opt/rucio/certs/long.proxy
-            subPath: long.proxy
-        additionalEnvs:
-          - name: RUCIO_LONG_PROXY
-            value: long.proxy
-          - name: RUCIO_FTS_SECRETS
-            value: release-rucio-x509up
+```yaml
+script: atlas
+vos:
+  - vo: "atlas"
+    voms: "atlas:/atlas/Role=production"
+secretMounts:
+  - secretFullName: release-longproxy
+    mountPath: /opt/rucio/certs/long.proxy
+    subPath: long.proxy
+additionalEnvs:
+  - name: RUCIO_LONG_PROXY
+    value: long.proxy
+  - name: RUCIO_FTS_SECRETS
+    value: release-rucio-x509up
+```
 
 
 ### Reaper
@@ -99,44 +109,54 @@ In case you need any additional secrets, e.g., special cloud configurations, lic
 `secretMounts` in the configuration file. You can install arbitrary secrets in the cluster and this config 
 then makes it available in the pods:
 
-    $ kubectl create secret generic my-release-automatix-input --from-file=automatix.json
+  ```sh
+  kubectl create secret generic my-release-automatix-input --from-file=automatix.json
+  ```
 
-    secretMounts:
-      - secretName: automatix-input
-        mountPath: /opt/rucio/etc/automatix.json
-        subPath: automatix.json
+```yaml
+secretMounts:
+  - secretName: automatix-input
+    mountPath: /opt/rucio/etc/automatix.json
+    subPath: automatix.json
+```
 
 This will create the file from the secret and place it at `/opt/rucio/etc/automatix.json` in every daemon container.
 
 ## Automatic Restarts
 
 In case you want to add regular restarts for your pods there a is a cronjob available that can be configured like this:
 
-    automaticRestart:
-      enabled: 1
-      schedule: "15 1 * * *"
+```yaml
+automaticRestart:
+  enabled: 1
+  schedule: "15 1 * * *"
+```
 
 This will run according to the given schedule and do a `kubectl rollout restart deployment` for all daemons.
 
 ## Prometheus Monitoring
 
 In case you have Prometheus running in your cluster you can use the built-in exporter to let Prometheus automatically scrape your metrics:
 
-    monitoring:
-      enabled: true
-      exporterPort: 8080
-      targetPort: 8080
-      interval: 30s
-      telemetryPath: /metrics
-      namespace: monitoring
-      labels:
-        release: prometheus-operator
+```yaml
+monitoring:
+  enabled: true
+  exporterPort: 8080
+  targetPort: 8080
+  interval: 30s
+  telemetryPath: /metrics
+  namespace: monitoring
+  labels:
+    release: prometheus-operator
+```
 
 ## Uninstalling the Chart
 
 To uninstall/delete the `my-release` deployment:
 
-    $ helm delete my-release --purge
+  ```sh
+  helm uninstall my-release
+  ```
 
 The command removes all the Kubernetes components associated with the chart and deletes the release.
 

charts/rucio-server/Chart.yaml

@@ -1,5 +1,5 @@
 name: rucio-server
-version: 38.0.4
+version: 38.0.5
 apiVersion: v1
 description: A Helm chart to deploy servers for Rucio
 keywords: