Update docs

Signed-off-by: Tamal Saha <[email protected]>

content/docs/v2024.9.30/guides/druid/backup/application-level/index.md

@@ -251,7 +251,7 @@ spec:
   version: 30.0.0
 ```
 
-KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section.
+KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to be set in AppBinding's `.spec` section.
 
 - `.spec.clientConfig.service.name` specifies the name of the Service that connects to the database.
 - `.spec.secret` specifies the name of the Secret that holds necessary credentials to access the database.
@@ -800,4 +800,4 @@ kubectl delete retentionpolicies.storage.kubestash.com -n demo demo-retention
 kubectl delete restoresessions.core.kubestash.com -n demo restore-sample-druid
 kubectl delete druid -n demo sample-druid
 kubectl delete druid -n dev restored-druid
-```
+```

content/docs/v2024.9.30/guides/druid/backup/auto-backup/index.md

@@ -197,7 +197,7 @@ spec:
 
 Here,
 
-- `.spec.backupConfigurationTemplate.backends[*].storageRef` refers our earlier created `gcs-storage` backupStorage.
+- `.spec.backupConfigurationTemplate.backends[*].storageRef` refers to our earlier created `gcs-storage` backupStorage.
 - `.spec.backupConfigurationTemplate.sessions[*].schedule` specifies that we want to backup the database at `5 minutes` interval.
 
 Let's create the `BackupBlueprint` we have shown above,
@@ -207,7 +207,7 @@ $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >
 backupblueprint.core.kubestash.com/druid-default-backup-blueprint created
 ```
 
-Now, we are ready to backup our `Druid` databases using few annotations.
+Now, we are ready to backup our `Druid` databases using a few annotations.
 
 ## Deploy Sample Druid Database
 
@@ -825,4 +825,4 @@ kubectl delete secret -n demo encrypt-secret
 kubectl delete retentionpolicies.storage.kubestash.com -n demo demo-retention
 kubectl delete druid -n demo sample-druid
 kubectl delete druid -n demo sample-druid-2
-```
+```

content/docs/v2024.9.30/guides/druid/concepts/appbinding.md

@@ -29,7 +29,7 @@ info:
 
 An `AppBinding` is a Kubernetes `CustomResourceDefinition`(CRD) which points to an application using either its URL (usually for a non-Kubernetes resident service instance) or a Kubernetes service object (if self-hosted in a Kubernetes cluster), some optional parameters and a credential secret. To learn more about AppBinding and the problems it solves, please read this blog post: [The case for AppBinding](https://appscode.com/blog/post/the-case-for-appbinding).
 
-If you deploy a database using [KubeDB](https://kubedb.com/docs/0.11.0/concepts/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database.
+If you deploy a database using [KubeDB](https://kubedb.com/docs/latest/welcome/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database.
 
 KubeDB uses [Stash](https://appscode.com/products/stash/) to perform backup/recovery of databases. Stash needs to know how to connect with a target database and the credentials necessary to access it. This is done via an `AppBinding`.
 

content/docs/v2024.9.30/guides/mariadb/concepts/appbinding/index.md

@@ -29,7 +29,7 @@ info:
 
 An `AppBinding` is a Kubernetes `CustomResourceDefinition`(CRD) which points to an application using either its URL (usually for a non-Kubernetes resident service instance) or a Kubernetes service object (if self-hosted in a Kubernetes cluster), some optional parameters and a credential secret. To learn more about AppBinding and the problems it solves, please read this blog post: [The case for AppBinding](https://appscode.com/blog/post/the-case-for-appbinding).
 
-If you deploy a database using [KubeDB](https://kubedb.com/docs/0.11.0/concepts/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database.
+If you deploy a database using [KubeDB](https://kubedb.com/docs/latest/welcome/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database.
 
 KubeDB uses [Stash](https://appscode.com/products/stash/) to perform backup/recovery of databases. Stash needs to know how to connect with a target database and the credentials necessary to access it. This is done via an `AppBinding`.
 

content/docs/v2024.9.30/guides/memcached/concepts/appbinding.md

@@ -29,7 +29,7 @@ info:
 
 An `AppBinding` is a Kubernetes `CustomResourceDefinition`(CRD) which points to an application using either its URL (usually for a non-Kubernetes resident service instance) or a Kubernetes service object (if self-hosted in a Kubernetes cluster), some optional parameters and a credential secret. To learn more about AppBinding and the problems it solves, please read this blog post: [The case for AppBinding](https://appscode.com/blog/post/the-case-for-appbinding).
 
-If you deploy a database using [KubeDB](https://kubedb.com/docs/0.11.0/concepts/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database.
+If you deploy a database using [KubeDB](https://kubedb.com/docs/latest/welcome/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database.
 
 KubeDB uses [Stash](https://appscode.com/products/stash/) to perform backup/recovery of databases. Stash needs to know how to connect with a target database and the credentials necessary to access it. This is done via an `AppBinding`.
 

content/docs/v2024.9.30/guides/mongodb/backup/kubestash/application-level/index.md

@@ -250,7 +250,7 @@ We are going to store our backed up data into a `S3` bucket. At first, we need t
 
 Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket,
 
-```console
+```bash
 $ echo -n '<your-aws-access-key-id-here>' > AWS_ACCESS_KEY_ID
 $ echo -n '<your-aws-secret-access-key-here>' > AWS_SECRET_ACCESS_KEY
 $ kubectl create secret generic -n demo s3-secret \
@@ -301,7 +301,7 @@ We have to create a `BackupConfiguration` targeting respective MongoDB crd of ou
 
 EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret`
 
-```console
+```bash
 $ kubectl create secret generic encry-secret -n demo \
     --from-literal=RESTIC_PASSWORD='123' -n demo
 secret/encry-secret created
@@ -328,7 +328,7 @@ spec:
 
 Let's create the RetentionPolicy we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/application-level/examples/retentionpolicy.yaml
 retentionpolicy.storage.kubestash.com/backup-rp created
 ```

content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/index.md

@@ -47,7 +47,7 @@ You should be familiar with the following `KubeStash` concepts:
 
 To keep things isolated, we are going to use a separate namespace called `demo` throughout this tutorial. Create `demo` namespace if you haven't created yet.
 
-```console
+```bash
 $ kubectl create ns demo
 namespace/demo created
 ```
@@ -64,7 +64,7 @@ We are going to store our backed up data into a S3 bucket. At first, we need to
 
 Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket,
 
-```console
+```bash
 $ echo -n '<your-aws-access-key-id-here>' > AWS_ACCESS_KEY_ID
 $ echo -n '<your-aws-secret-access-key-here>' > AWS_SECRET_ACCESS_KEY
 $ kubectl create secret generic -n demo s3-secret \
@@ -100,7 +100,7 @@ spec:
 
 Let's create the `BackupStorage` we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupstorage.yaml
 backupstorage.storage.kubestash.com/s3-storage created
 ```
@@ -110,7 +110,7 @@ We also need to create an secret for encrypt data and retention policy for `Back
 
 EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret`
 
-```console
+```bash
 $ kubectl create secret generic encry-secret -n demo \
     --from-literal=RESTIC_PASSWORD='123' -n demo
 secret/encry-secret created
@@ -137,7 +137,7 @@ spec:
 
 Let's create the RetentionPolicy we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/auto-backup/examples/retentionpolicy.yaml
 retentionpolicy.storage.kubestash.com/backup-rp created
 ```

content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/index.md

@@ -44,7 +44,7 @@ You have to be familiar with following custom resources:
 
 To keep things isolated, we are going to use a separate namespace called `demo` throughout this tutorial. Create `demo` namespace if you haven't created yet.
 
-```console
+```bash
 $ kubectl create ns demo
 namespace/demo created
 ```
@@ -84,7 +84,7 @@ spec:
 
 Create the above `MongoDB` crd,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset.yaml
 mongodb.kubedb.com/sample-mg-rs created
 ```
@@ -93,15 +93,15 @@ KubeDB will deploy a MongoDB database according to the above specification. It w
 
 Let's check if the database is ready to use,
 
-```console
+```bash
 $ kubectl get mongodb -n demo sample-mg-rs
 NAME           VERSION   STATUS   AGE
 sample-mg-rs   4.2.24     Ready    2m27s
 ```
 
 The database is `Ready`. Verify that KubeDB has created a Secret and a Service for this database using the following commands,
 
-```console
+```bash
 $ kubectl get secret -n demo -l=app.kubernetes.io/instance=sample-mg-rs
 NAME                TYPE                       DATA   AGE
 sample-mg-rs-auth   kubernetes.io/basic-auth   2      3m53s
@@ -121,7 +121,7 @@ Here, we have to use service `sample-mg-rs` and secret `sample-mg-rs-auth` to co
 
 For simplicity, we are going to exec into the database pod and create some sample data. At first, find out the database pod using the following command,
 
-```console
+```bash
 $ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-mg-rs"
 NAME             READY   STATUS    RESTARTS   AGE
 sample-mg-rs-0   2/2     Running   0          6m15s
@@ -131,7 +131,7 @@ sample-mg-rs-2   2/2     Running   0          5m14s
 
 Now, let's exec into the pod and create a table,
 
-```console
+```bash
 $ export USER=$(kubectl get secrets -n demo sample-mg-rs-auth -o jsonpath='{.data.\username}' | base64 -d)
 
 $ export PASSWORD=$(kubectl get secrets -n demo sample-mg-rs-auth -o jsonpath='{.data.\password}' | base64 -d)
@@ -186,7 +186,7 @@ We are going to store our backed up data into a S3 bucket. At first, we need to
 
 Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket,
 
-```console
+```bash
 $ echo -n '<your-aws-access-key-id-here>' > AWS_ACCESS_KEY_ID
 $ echo -n '<your-aws-secret-access-key-here>' > AWS_SECRET_ACCESS_KEY
 $ kubectl create secret generic -n demo s3-secret \
@@ -222,7 +222,7 @@ spec:
 
 Let's create the `BackupStorage` we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupstorage-replicaset.yaml
 backupstorage.storage.kubestash.com/s3-storage-replicaset created
 ```
@@ -237,7 +237,7 @@ We have to create a `BackupConfiguration` targeting respective MongoDB crd of ou
 
 EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret`
 
-```console
+```bash
 $ kubectl create secret generic encry-secret -n demo \
     --from-literal=RESTIC_PASSWORD='123' -n demo
 secret/encry-secret created
@@ -264,7 +264,7 @@ spec:
 
 Let's create the RetentionPolicy we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/retentionpolicy.yaml
 retentionpolicy.storage.kubestash.com/backup-rp created
 ```
@@ -324,7 +324,7 @@ Here,
 
 Let's create the `BackupConfiguration` crd we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml
 backupconfiguration.core.kubestash.com/mg created
 ```
@@ -333,7 +333,7 @@ backupconfiguration.core.kubestash.com/mg created
 
 If everything goes well, the phase of the `BackupConfiguration` should be `Ready`. The `Ready` phase indicates that the backup setup is successful. Let's verify the `Phase` of the BackupConfiguration,
 
-```console
+```bash
 $ kubectl get backupconfiguration -n demo
 NAME   PHASE   PAUSED   AGE
 mg     Ready            85s
@@ -345,7 +345,7 @@ KubeStash will create a CronJob with the schedule specified in `spec.sessions.sc
 
 Verify that the CronJob has been created using the following command,
 
-```console
+```bash
 $ kubectl get cronjob -n demo
 NAME                  SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
 trigger-mg-frequent   */3 * * * *   False     0        <none>          101s
@@ -357,7 +357,7 @@ The `trigger-mg-frequent` CronJob will trigger a backup on each schedule by crea
 
 Wait for the next schedule. Run the following command to watch `BackupSession` crd,
 
-```console
+```bash
 $ kubectl get backupsession -n demo
 NAME                     INVOKER-TYPE          INVOKER-NAME   PHASE       DURATION   AGE
 mg-frequent-1701940862   BackupConfiguration   mg             Succeeded              3m16s
@@ -370,7 +370,7 @@ We can see above that the backup session has succeeded. Now, we are going to ver
 
 Once a backup is complete, KubeStash will update the respective `Snapshot` crd to reflect the backup. It will be created when a backup is triggered. Check that the `Snapshot` Phase to verify backup.
 
-```console
+```bash
 $ kubectl get snapshot -n demo
 NAME                             REPOSITORY   SESSION    SNAPSHOT-TIME          DELETION-POLICY   PHASE       VERIFICATION-STATUS   AGE
 s3-repo-mg-frequent-1701940862   s3-repo      frequent   2023-12-07T09:21:07Z   Delete            Succeeded                         3m53s
@@ -379,7 +379,7 @@ s3-repo-mg-frequent-1701941042   s3-repo      frequent   2023-12-07T09:24:08Z
 
 KubeStash will also update the respective `Repository` crd to reflect the backup. Check that the repository `s3-repo` has been updated by the following command,
 
-```console
+```bash
 $ kubectl get repository -n demo s3-repo
 NAME      INTEGRITY   SNAPSHOT-COUNT   SIZE        PHASE   LAST-SUCCESSFUL-BACKUP   AGE
 s3-repo   true        2                2.883 KiB   Ready   55s                      8m5s
@@ -404,7 +404,7 @@ backupconfiguration.core.kubestash.com/mg patched
 
 Now, wait for a moment. KubeStash will pause the BackupConfiguration. Verify that the BackupConfiguration  has been paused,
 
-```console
+```bash
 $ kubectl get backupconfiguration -n demo mg
 NAME   PHASE   PAUSED   AGE
 mg     Ready   true     11m
@@ -441,22 +441,22 @@ spec:
 
 Create the above `MongoDB` crd,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset-restore.yaml
 mongodb.kubedb.com/sample-mg-rs-restore created
 ```
 
 Let's check if the database is ready to use,
 
-```console
+```bash
 $ kubectl get mg -n demo sample-mg-rs-restore
 NAME                   VERSION   STATUS   AGE
 sample-mg-rs-restore   4.2.24     Ready    2m45s
 ```
 
 Let's verify all the databases of this `sample-mg-rs-restore` by exec into its pod
 
-```console
+```bash
 $ export USER=$(kubectl get secrets -n demo sample-mg-rs-restore-auth -o jsonpath='{.data.\username}' | base64 -d)
 
 $ export PASSWORD=$(kubectl get secrets -n demo sample-mg-rs-restore-auth -o jsonpath='{.data.\password}' | base64 -d)
@@ -530,7 +530,7 @@ Here,
 
 Let's create the `RestoreSession` crd we have shown above,
 
-```console
+```bash
 $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml
 restoresession.core.kubestash.com/mg-rs-restore created
 ```
@@ -539,7 +539,7 @@ Once, you have created the `RestoreSession` crd, KubeStash will create a job to
 
 Run the following command to watch `RestoreSession` phase,
 
-```console
+```bash
 $ kubectl get restoresession -n demo mg-rs-restore -w
 NAME            REPOSITORY   FAILURE-POLICY   PHASE       DURATION   AGE
 mg-rs-restore   s3-repo                       Succeeded   9s         34s
@@ -553,7 +553,7 @@ In this section, we are going to verify that the desired data has been restored
 
 Lets, exec into the database pod and list available tables,
 
-```console
+```bash
 $ kubectl exec -it -n demo sample-mg-rs-restore-0 -- mongo admin -u $USER -p $PASSWORD
 
 rs0:PRIMARY> show dbs
@@ -597,7 +597,7 @@ So, from the above output, we can see the database `newdb` that we had created e
 
 To cleanup the Kubernetes resources created by this tutorial, run:
 
-```console
+```bash
 kubectl delete -n demo restoresession mg-rs-restore
 kubectl delete -n demo backupconfiguration mg
 kubectl delete -n demo mg sample-mg-rs