Update druid

Signed-off-by: Neaj Morshad <[email protected]>
kubedb · Dec 20, 2024 · d11485e · d11485e
1 parent 8ded980
commit d11485e
Show file tree

Hide file tree

Showing 14 changed files with 47 additions and 46 deletions.
diff --git a/docs/guides/druid/backup/application-level/examples/sample-druid.yaml b/docs/guides/druid/backup/application-level/examples/sample-druid.yaml
@@ -4,7 +4,7 @@ metadata:
   name: sample-druid
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:

diff --git a/docs/guides/druid/backup/application-level/index.md b/docs/guides/druid/backup/application-level/index.md
@@ -114,7 +114,7 @@ metadata:
   name: sample-druid
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:
@@ -143,7 +143,7 @@ Let's check if the database is ready to use,
 ```bash
 $ kubectl get druids.kubedb.com -n demo
 NAME           TYPE                  VERSION   STATUS   AGE
-sample-druid   kubedb.com/v1alpha2   30.0.0    Ready    4m14s
+sample-druid   kubedb.com/v1alpha2   30.0.1    Ready    4m14s
 ```
 
 The database is `Ready`. Verify that KubeDB has created a `Secret` and a `Service` for this database using the following commands,
@@ -183,7 +183,7 @@ Verify that the `AppBinding` has been created successfully using the following c
 ```bash
 $ kubectl get appbindings -n demo
 NAME                          TYPE                   VERSION   AGE
-sample-druid                  kubedb.com/druid       30.0.0    4m7s
+sample-druid                  kubedb.com/druid       30.0.1    4m7s
 sample-druid-mysql-metadata   kubedb.com/mysql       8.0.35    6m31s
 sample-druid-zk               kubedb.com/zookeeper   3.7.2     6m34s
 ```
@@ -202,7 +202,7 @@ kind: AppBinding
 metadata:
   annotations:
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"kubedb.com/v1alpha2","kind":"Druid","metadata":{"annotations":{},"name":"sample-druid","namespace":"demo"},"spec":{"deepStorage":{"configSecret":{"name":"deep-storage-config"},"type":"s3"},"deletionPolicy":"WipeOut","topology":{"routers":{"replicas":1}},"version":"30.0.0"}}
+      {"apiVersion":"kubedb.com/v1alpha2","kind":"Druid","metadata":{"annotations":{},"name":"sample-druid","namespace":"demo"},"spec":{"deepStorage":{"configSecret":{"name":"deep-storage-config"},"type":"s3"},"deletionPolicy":"WipeOut","topology":{"routers":{"replicas":1}},"version":"30.0.1"}}
   creationTimestamp: "2024-09-19T13:02:20Z"
   generation: 1
   labels:
@@ -236,7 +236,7 @@ spec:
   secret:
     name: sample-druid-admin-cred
   type: kubedb.com/druid
-  version: 30.0.0
+  version: 30.0.1
 ```
 
 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.
@@ -544,7 +544,7 @@ apiVersion: storage.kubestash.com/v1alpha1
 kind: Snapshot
 metadata:
   annotations:
-    kubedb.com/db-version: 30.0.0
+    kubedb.com/db-version: 30.0.1
   creationTimestamp: "2024-09-20T11:09:00Z"
   finalizers:
     - kubestash.com/cleanup
@@ -707,7 +707,7 @@ In this section, we will verify whether the desired `Druid` database manifest ha
 ```bash
 $ kubectl get druids.kubedb.com -n dev
 NAME           VERSION   STATUS   AGE
-restored-druid   30.0.0    Ready    39m
+restored-druid   30.0.1    Ready    39m
 ```
 
 The output confirms that the `Druid` database has been successfully created with the same configuration as it had at the time of backup.
@@ -733,7 +733,7 @@ At first, check if the database has gone into `Ready` state by the following com
 ```bash
 $ kubectl get druid -n dev restored-druid
 NAME             VERSION   STATUS  AGE
-restored-druid   30.0.0    Ready   34m
+restored-druid   30.0.1    Ready   34m
 ```
 
 Now, let's verify if our datasource `wikipedia` exists or not. For that, first find out the database `Sevices` by the following command,

diff --git a/docs/guides/druid/backup/auto-backup/examples/sample-druid-2.yaml b/docs/guides/druid/backup/auto-backup/examples/sample-druid-2.yaml
@@ -12,7 +12,7 @@ metadata:
     variables.kubestash.com/targetName: sample-druid-2
     variables.kubestash.com/targetedDatabases: druid
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:

diff --git a/docs/guides/druid/backup/auto-backup/examples/sample-druid.yaml b/docs/guides/druid/backup/auto-backup/examples/sample-druid.yaml
@@ -7,7 +7,7 @@ metadata:
     blueprint.kubestash.com/name: druid-default-backup-blueprint
     blueprint.kubestash.com/namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:

diff --git a/docs/guides/druid/backup/auto-backup/index.md b/docs/guides/druid/backup/auto-backup/index.md
@@ -266,7 +266,7 @@ metadata:
     blueprint.kubestash.com/name: druid-default-backup-blueprint
     blueprint.kubestash.com/namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:
@@ -438,7 +438,7 @@ metadata:
     kubestash.com/app-ref-namespace: demo
     kubestash.com/repo-name: default-blueprint
   annotations:
-    kubedb.com/db-version: 30.0.0
+    kubedb.com/db-version: 30.0.1
   name: default-blueprint-appbinding-samruid-frequent-backup-1726741846
   namespace: demo
   ownerReferences:
@@ -586,7 +586,7 @@ metadata:
     variables.kubestash.com/targetName: sample-druid-2
     variables.kubestash.com/targetedDatabases: druid
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:
@@ -754,7 +754,7 @@ metadata:
     kubestash.com/app-ref-namespace: demo
     kubestash.com/repo-name: customize-blueprint
   annotations:
-    kubedb.com/db-version: 30.0.0
+    kubedb.com/db-version: 30.0.1
   name: customize-blueprint-appbinding-sid-2-frequent-backup-1726743656
   namespace: demo
   ownerReferences:

diff --git a/docs/guides/druid/backup/cross-ns-dependencies/examples/sample-druid.yaml b/docs/guides/druid/backup/cross-ns-dependencies/examples/sample-druid.yaml
@@ -4,7 +4,7 @@ metadata:
   name: sample-druid
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   zookeeperRef:
     name: zk-dev
     namespace: dev

diff --git a/docs/guides/druid/backup/cross-ns-dependencies/index.md b/docs/guides/druid/backup/cross-ns-dependencies/index.md
@@ -121,7 +121,7 @@ metadata:
   name: sample-druid
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   zookeeperRef:
     name: zk-dev
     namespace: dev
@@ -158,7 +158,7 @@ Let's check if the database is ready to use,
 ```bash
 $ kubectl get druids.kubedb.com -n demo
 NAME           TYPE                  VERSION   STATUS   AGE
-sample-druid   kubedb.com/v1alpha2   30.0.0    Ready    4m14s
+sample-druid   kubedb.com/v1alpha2   30.0.1    Ready    4m14s
 ```
 
 The database is `Ready`. Verify that KubeDB has created a `Secret` and a `Service` for this database using the following commands,
@@ -199,7 +199,7 @@ Verify that the `AppBinding` has been created successfully using the following c
 ```bash
 $ kubectl get appbindings -n demo 
 NAME           TYPE                   VERSION   AGE
-sample-druid   kubedb.com/druid       30.0.0    4m7s
+sample-druid   kubedb.com/druid       30.0.1    4m7s
 
 $ kubectl get appbindings -n dev1 
 NAME           TYPE                   VERSION   AGE
@@ -224,7 +224,7 @@ kind: AppBinding
 metadata:
   annotations:
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"kubedb.com/v1alpha2","kind":"Druid","metadata":{"annotations":{},"name":"sample-druid","namespace":"demo"},"spec":{"deepStorage":{"configSecret":{"name":"deep-storage-config"},"type":"s3"},"deletionPolicy":"WipeOut","topology":{"routers":{"replicas":1}},"version":"30.0.0"}}
+      {"apiVersion":"kubedb.com/v1alpha2","kind":"Druid","metadata":{"annotations":{},"name":"sample-druid","namespace":"demo"},"spec":{"deepStorage":{"configSecret":{"name":"deep-storage-config"},"type":"s3"},"deletionPolicy":"WipeOut","topology":{"routers":{"replicas":1}},"version":"30.0.1"}}
   creationTimestamp: "2024-09-19T13:02:20Z"
   generation: 1
   labels:
@@ -258,7 +258,7 @@ spec:
   secret:
     name: sample-druid-admin-cred
   type: kubedb.com/druid
-  version: 30.0.0
+  version: 30.0.1
 ```
 
 KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section.
@@ -638,7 +638,7 @@ apiVersion: storage.kubestash.com/v1alpha1
 kind: Snapshot
 metadata:
   annotations:
-    kubedb.com/db-version: 30.0.0
+    kubedb.com/db-version: 30.0.1
   creationTimestamp: "2024-09-20T11:09:00Z"
   finalizers:
     - kubestash.com/cleanup
@@ -806,7 +806,7 @@ In this section, we will verify whether the desired `Druid` database manifest ha
 ```bash
 $ kubectl get druids.kubedb.com -n demo
 NAME           VERSION   STATUS   AGE
-restored-druid   30.0.0  Ready    6m26s
+restored-druid   30.0.1  Ready    6m26s
 ```
 
 The output confirms that the `Druid` database has been successfully created with the same configuration as it had at the time of backup.
@@ -833,7 +833,7 @@ At first, check if the database has gone into `Ready` state by the following com
 ```bash
 $ kubectl get druid -n demo restored-druid
 NAME             VERSION   STATUS  AGE
-restored-druid   30.0.0    Ready   34m
+restored-druid   30.0.1    Ready   34m
 ```
 
 Now, let's verify if our datasource `wikipedia` exists or not. For that, first find out the database `Sevices` by the following command,

diff --git a/docs/guides/druid/backup/customization/examples/common/sample-druid.yaml b/docs/guides/druid/backup/customization/examples/common/sample-druid.yaml
@@ -4,7 +4,7 @@ metadata:
   name: sample-druid
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:

diff --git a/docs/guides/druid/backup/logical/examples/restored-druid.yaml b/docs/guides/druid/backup/logical/examples/restored-druid.yaml
@@ -6,7 +6,7 @@ metadata:
 spec:
   init:
     waitForInitialRestore: true
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:

diff --git a/docs/guides/druid/backup/logical/examples/sample-druid.yaml b/docs/guides/druid/backup/logical/examples/sample-druid.yaml
@@ -4,7 +4,7 @@ metadata:
   name: sample-druid
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:

diff --git a/docs/guides/druid/backup/logical/index.md b/docs/guides/druid/backup/logical/index.md
@@ -115,7 +115,7 @@ metadata:
   name: druid-quickstart
   namespace: demo
 spec:
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:
@@ -140,7 +140,7 @@ Let's check if the database is ready to use,
 ```bash
 $ kubectl get druids.kubedb.com -n demo
 NAME               TYPE                  VERSION   STATUS         AGE
-sample-druid       kubedb.com/v1alpha2   30.0.0    Ready          113s
+sample-druid       kubedb.com/v1alpha2   30.0.1    Ready          113s
 ```
 
 The database is `Ready`. Verify that KubeDB has created the necessary `Secrets` and `Services` to access the database along with `MySQL` and `ZooKeeper` instance for this database using the following commands,
@@ -167,7 +167,7 @@ Verify that the `AppBinding` has been created successfully using the following c
 ```bash
 $ kubectl get appbindings -n demo
 NAME                          TYPE                   VERSION   AGE
-sample-druid                  kubedb.com/druid       30.0.0    2m26s
+sample-druid                  kubedb.com/druid       30.0.1    2m26s
 sample-druid-mysql-metadata   kubedb.com/mysql       8.0.35    5m40s
 sample-druid-zk               kubedb.com/zookeeper   3.7.2     5m43s
 ```
@@ -184,7 +184,7 @@ kind: AppBinding
 metadata:
   annotations:
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"kubedb.com/v1alpha2","kind":"Druid","metadata":{"annotations":{},"name":"sample-druid","namespace":"demo"},"spec":{"deepStorage":{"configSecret":{"name":"deep-storage-config"},"type":"s3"},"deletionPolicy":"WipeOut","topology":{"routers":{"replicas":1}},"version":"30.0.0"}}
+      {"apiVersion":"kubedb.com/v1alpha2","kind":"Druid","metadata":{"annotations":{},"name":"sample-druid","namespace":"demo"},"spec":{"deepStorage":{"configSecret":{"name":"deep-storage-config"},"type":"s3"},"deletionPolicy":"WipeOut","topology":{"routers":{"replicas":1}},"version":"30.0.1"}}
   creationTimestamp: "2024-09-17T12:17:27Z"
   generation: 1
   labels:
@@ -218,7 +218,7 @@ spec:
   secret:
     name: sample-druid-admin-cred
   type: kubedb.com/druid
-  version: 30.0.0
+  version: 30.0.1
 ```
 
 KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section.
@@ -530,7 +530,7 @@ metadata:
     kubestash.com/app-ref-namespace: demo
     kubestash.com/repo-name: gcs-druid-repo
   annotations:
-    kubedb.com/db-version: 30.0.0
+    kubedb.com/db-version: 30.0.1
   name: gcs-druid-repo-sample-druid-backup-frequent-backup-1726656835
   namespace: demo
   ownerReferences:
@@ -599,7 +599,7 @@ metadata:
 spec:
   init:
     waitForInitialRestore: true
-  version: 30.0.0
+  version: 30.0.1
   deepStorage:
     type: s3
     configSecret:
@@ -622,7 +622,7 @@ If you check the database status, you will see it is stuck in `Provisioning` sta
 ```bash
 $ kubectl get druid -n demo restored-druid
 NAME             TYPE                  VERSION   STATUS         AGE
-restored-druid   kubedb.com/v1alpha2   30.0.0    Provisioning   22s
+restored-druid   kubedb.com/v1alpha2   30.0.1    Provisioning   22s
 ```
 
 #### Create RestoreSession:

diff --git a/docs/guides/druid/concepts/druid.md b/docs/guides/druid/concepts/druid.md
@@ -162,15 +162,16 @@ spec:
         labels:
           release: prometheus
         interval: 10s
-  version: 30.0.0
+  version: 30.0.1
 ```
 
 ### spec.version
 
 `spec.version` is a required field specifying the name of the [DruidVersion](/docs/guides/druid/concepts/druidversion.md) crd where the docker images are specified. Currently, when you install KubeDB, it creates the following `Druid` resources,
 
 - `28.0.1`
-- `30.0.0`
+- `30.0.1`
+- `31.0.1`
 
 ### spec.replicas
 

diff --git a/docs/guides/druid/update-version/guide.md b/docs/guides/druid/update-version/guide.md
@@ -172,7 +172,7 @@ Here, we can see that the version of the druid cluster is `28.0.1`.
 
 ### Update Druid Version
 
-Here, we are going to update `Druid` from `28.0.1` to `30.0.0`.
+Here, we are going to update `Druid` from `28.0.1` to `30.0.1`.
 
 #### Create DruidOpsRequest:
 
@@ -189,7 +189,7 @@ spec:
   databaseRef:
     name: druid-cluster
   updateVersion:
-    targetVersion: 30.0.0
+    targetVersion: 30.0.1
   timeout: 5m
   apply: IfReady
 ```
@@ -198,7 +198,7 @@ Here,
 
 - `spec.databaseRef.name` specifies that we are performing operation on `druid-cluster` Druid.
 - `spec.type` specifies that we are going to perform `UpdateVersion` on our database.
-- `spec.updateVersion.targetVersion` specifies the expected version of the database `30.0.0`.
+- `spec.updateVersion.targetVersion` specifies the expected version of the database `30.0.1`.
 
 Let's create the `DruidOpsRequest` CR we have shown above,
 
@@ -273,7 +273,7 @@ Spec:
   Timeout:  5m
   Type:     UpdateVersion
   Update Version:
-    Target Version:  30.0.0
+    Target Version:  30.0.1
 Status:
   Conditions:
     Last Transition Time:  2024-10-21T13:04:51Z
@@ -407,13 +407,13 @@ Now, we are going to verify whether the `Druid` and the related `PetSets` and th
 
 ```bash
 $ kubectl get dr -n demo druid-cluster -o=jsonpath='{.spec.version}{"\n"}'
-30.0.0
+30.0.1
 
 $ kubectl get petset -n demo druid-cluster-brokers -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
-ghcr.io/appscode-images/druid:30.0.0@sha256:4cd60a1dc6a124e27e91ec52ca39e2b9ca6809df915ae2dd712a2dd7462626d7
+ghcr.io/appscode-images/druid:30.0.1@sha256:4cd60a1dc6a124e27e91ec52ca39e2b9ca6809df915ae2dd712a2dd7462626d7
 
 $ kubectl get pods -n demo druid-cluster-brokers-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}'
-ghcr.io/appscode-images/druid:30.0.0
+ghcr.io/appscode-images/druid:30.0.1
 ```
 
 You can see from above, our `Druid` has been updated with the new version. So, the updateVersion process is successfully completed.
@@ -422,7 +422,7 @@ You can see from above, our `Druid` has been updated with the new version. So, t
 
 You can also see the version of druid cluster from the druid ui by following the steps described previously in this tutorial. [Check Druid Version from UI](/docs/guides/druid/update-version/guide.md/#Check-Druid-Version-from-UI)
 
-If you follow the steps properly, you should be able to see that the version is upgraded to `30.0.0` from the druid console as shown below.
+If you follow the steps properly, you should be able to see that the version is upgraded to `30.0.1` from the druid console as shown below.
 
 <p align="center">
   <img alt="lifecycle"  src="/docs/guides/druid/update-version/images/druid-ui-30.png">