From 7da00657863c881beafff93ae2081305c5f60eb9 Mon Sep 17 00:00:00 2001 From: Arnob Kumar Saha Date: Wed, 24 Apr 2024 15:36:29 +0600 Subject: [PATCH] Fix all broken schemas, resource-yamls & links (#629) Signed-off-by: Arnob kumar saha --- .../mongodb/autoscaling/storage/mg-as-rs.yaml | 1 + .../mongodb/autoscaling/storage/mg-as-sh.yaml | 1 + .../autoscaling/storage/mg-as-standalone.yaml | 1 + ...=> mops-reconfigure-apply-replicaset.yaml} | 7 +-- .../mops-reconfigure-apply-shard.yaml | 25 +++++++++++ ...=> mops-reconfigure-apply-standalone.yaml} | 7 +-- .../mops-reconfigure-inline-shard.yaml | 22 ---------- .../mops-volume-exp-replicaset.yaml | 1 + .../mops-volume-exp-shard.yaml | 1 + .../mops-volume-exp-standalone.yaml | 1 + .../redis/autoscaling/storage/rd-as.yaml | 1 + ...econfig.yaml => rdops-apply-reconfig.yaml} | 4 +- .../autoscaler/storage/combined/index.md | 1 + .../yamls/es-combined-storage-as.yaml | 1 + .../autoscaler/storage/topology/index.md | 1 + .../yamls/es-topology-storage-as.yaml | 1 + .../concepts/appbinding/index.md | 2 +- .../concepts/autoscaler/index.md | 2 + .../concepts/elasticsearch-dashboard/index.md | 2 +- .../elasticsearch-ops-request/index.md | 3 ++ .../concepts/elasticsearch/index.md | 2 +- .../elasticsearch-dashboard/kibana/index.md | 6 +-- .../kibana/yamls/es-cluster-dashboard.yaml | 2 +- .../opensearch-dashboards/index.md | 6 +-- .../yamls/os-cluster-dashboard.yaml | 2 +- docs/guides/kafka/concepts/appbinding.md | 2 +- docs/guides/kafka/concepts/catalog.md | 2 + docs/guides/kafka/concepts/kafka.md | 2 +- .../mariadb/concepts/appbinding/index.md | 2 +- .../mariadb/concepts/opsrequest/index.md | 11 ++--- docs/guides/memcached/concepts/appbinding.md | 2 +- .../mongodb/autoscaler/storage/replicaset.md | 1 + .../mongodb/autoscaler/storage/sharding.md | 1 + .../mongodb/autoscaler/storage/standalone.md | 1 + docs/guides/mongodb/concepts/appbinding.md | 2 +- docs/guides/mongodb/concepts/autoscaler.md | 4 ++ docs/guides/mongodb/concepts/mongodb.md | 2 +- docs/guides/mongodb/concepts/opsrequest.md | 35 +++++++++------ docs/guides/mongodb/pitr/pitr.md | 2 +- docs/guides/mongodb/reconfigure/replicaset.md | 35 +++++++-------- docs/guides/mongodb/reconfigure/sharding.md | 43 ++++++++++--------- docs/guides/mongodb/reconfigure/standalone.md | 37 ++++++++-------- .../mongodb/volume-expansion/replicaset.md | 1 + .../mongodb/volume-expansion/sharding.md | 1 + .../mongodb/volume-expansion/standalone.md | 1 + .../guides/mysql/concepts/appbinding/index.md | 2 +- docs/guides/mysql/pitr/archiver.md | 2 +- .../mysql/pitr/yamls/backupstorage.yaml | 2 +- .../concepts/appbinding/index.md | 2 +- .../concepts/opsrequest/index.md | 9 ++-- docs/guides/pgbouncer/concepts/appbinding.md | 2 +- docs/guides/postgres/concepts/appbinding.md | 2 +- docs/guides/postgres/pitr/archiver.md | 2 +- .../postgres/pitr/yamls/backupstorage.yaml | 2 +- .../proxysql/concepts/appbinding/index.md | 2 +- docs/guides/redis/autoscaler/storage/redis.md | 1 + docs/guides/redis/concepts/appbinding.md | 2 +- docs/guides/redis/concepts/autoscaler.md | 1 + docs/guides/redis/concepts/redis.md | 2 +- docs/guides/redis/concepts/redissentinel.md | 2 +- docs/guides/redis/reconfigure/redis.md | 28 ++++++------ 61 files changed, 203 insertions(+), 150 deletions(-) rename docs/examples/mongodb/reconfigure/{mops-reconfigure-inline-replicaset.yaml => mops-reconfigure-apply-replicaset.yaml} (69%) create mode 100644 docs/examples/mongodb/reconfigure/mops-reconfigure-apply-shard.yaml rename docs/examples/mongodb/reconfigure/{mops-reconfigure-inline-standalone.yaml => mops-reconfigure-apply-standalone.yaml} (69%) delete mode 100644 docs/examples/mongodb/reconfigure/mops-reconfigure-inline-shard.yaml rename docs/examples/redis/reconfigure/{rdops-inline-reconfig.yaml => rdops-apply-reconfig.yaml} (76%) diff --git a/docs/examples/mongodb/autoscaling/storage/mg-as-rs.yaml b/docs/examples/mongodb/autoscaling/storage/mg-as-rs.yaml index 440c683205..adc4e4dd25 100644 --- a/docs/examples/mongodb/autoscaling/storage/mg-as-rs.yaml +++ b/docs/examples/mongodb/autoscaling/storage/mg-as-rs.yaml @@ -8,6 +8,7 @@ spec: name: mg-rs storage: replicaSet: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 \ No newline at end of file diff --git a/docs/examples/mongodb/autoscaling/storage/mg-as-sh.yaml b/docs/examples/mongodb/autoscaling/storage/mg-as-sh.yaml index 40e0ed3088..98351320aa 100644 --- a/docs/examples/mongodb/autoscaling/storage/mg-as-sh.yaml +++ b/docs/examples/mongodb/autoscaling/storage/mg-as-sh.yaml @@ -8,6 +8,7 @@ spec: name: mg-sh storage: shard: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 \ No newline at end of file diff --git a/docs/examples/mongodb/autoscaling/storage/mg-as-standalone.yaml b/docs/examples/mongodb/autoscaling/storage/mg-as-standalone.yaml index 3c197eedea..66b7be94ad 100644 --- a/docs/examples/mongodb/autoscaling/storage/mg-as-standalone.yaml +++ b/docs/examples/mongodb/autoscaling/storage/mg-as-standalone.yaml @@ -8,6 +8,7 @@ spec: name: mg-standalone storage: standalone: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 \ No newline at end of file diff --git a/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-replicaset.yaml b/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-replicaset.yaml similarity index 69% rename from docs/examples/mongodb/reconfigure/mops-reconfigure-inline-replicaset.yaml rename to docs/examples/mongodb/reconfigure/mops-reconfigure-apply-replicaset.yaml index 45bcafc44d..f0211d62a3 100644 --- a/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-replicaset.yaml +++ b/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-replicaset.yaml @@ -9,6 +9,7 @@ spec: name: mg-replicaset configuration: replicaSet: - inlineConfig: | - net: - maxIncomingConnections: 30000 + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 diff --git a/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-shard.yaml b/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-shard.yaml new file mode 100644 index 0000000000..68106de3d0 --- /dev/null +++ b/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-shard.yaml @@ -0,0 +1,25 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MongoDBOpsRequest +metadata: + name: mops-reconfigure-inline-shard + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mg-sharding + configuration: + shard: + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 + configServer: + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 + mongos: + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 \ No newline at end of file diff --git a/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-standalone.yaml b/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-standalone.yaml similarity index 69% rename from docs/examples/mongodb/reconfigure/mops-reconfigure-inline-standalone.yaml rename to docs/examples/mongodb/reconfigure/mops-reconfigure-apply-standalone.yaml index 53079b69fa..1ab3495453 100644 --- a/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-standalone.yaml +++ b/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-standalone.yaml @@ -9,6 +9,7 @@ spec: name: mg-standalone configuration: standalone: - inlineConfig: | - net: - maxIncomingConnections: 30000 + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 diff --git a/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-shard.yaml b/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-shard.yaml deleted file mode 100644 index 1f9bef23ac..0000000000 --- a/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-shard.yaml +++ /dev/null @@ -1,22 +0,0 @@ -apiVersion: ops.kubedb.com/v1alpha1 -kind: MongoDBOpsRequest -metadata: - name: mops-reconfigure-inline-shard - namespace: demo -spec: - type: Reconfigure - databaseRef: - name: mg-sharding - configuration: - shard: - inlineConfig: | - net: - maxIncomingConnections: 30000 - configServer: - inlineConfig: | - net: - maxIncomingConnections: 30000 - mongos: - inlineConfig: | - net: - maxIncomingConnections: 30000 diff --git a/docs/examples/mongodb/volume-expansion/mops-volume-exp-replicaset.yaml b/docs/examples/mongodb/volume-expansion/mops-volume-exp-replicaset.yaml index b6f22adf7f..f73cf0204a 100644 --- a/docs/examples/mongodb/volume-expansion/mops-volume-exp-replicaset.yaml +++ b/docs/examples/mongodb/volume-expansion/mops-volume-exp-replicaset.yaml @@ -8,4 +8,5 @@ spec: databaseRef: name: mg-replicaset volumeExpansion: + mode: "Online" replicaSet: 2Gi \ No newline at end of file diff --git a/docs/examples/mongodb/volume-expansion/mops-volume-exp-shard.yaml b/docs/examples/mongodb/volume-expansion/mops-volume-exp-shard.yaml index 73c1609445..9f29ec7074 100644 --- a/docs/examples/mongodb/volume-expansion/mops-volume-exp-shard.yaml +++ b/docs/examples/mongodb/volume-expansion/mops-volume-exp-shard.yaml @@ -8,5 +8,6 @@ spec: databaseRef: name: mg-sharding volumeExpansion: + mode: "Online" shard: 2Gi configServer: 2Gi \ No newline at end of file diff --git a/docs/examples/mongodb/volume-expansion/mops-volume-exp-standalone.yaml b/docs/examples/mongodb/volume-expansion/mops-volume-exp-standalone.yaml index 9c7e1188cb..5e356b9133 100644 --- a/docs/examples/mongodb/volume-expansion/mops-volume-exp-standalone.yaml +++ b/docs/examples/mongodb/volume-expansion/mops-volume-exp-standalone.yaml @@ -8,4 +8,5 @@ spec: databaseRef: name: mg-standalone volumeExpansion: + mode: "Online" standalone: 2Gi \ No newline at end of file diff --git a/docs/examples/redis/autoscaling/storage/rd-as.yaml b/docs/examples/redis/autoscaling/storage/rd-as.yaml index debe1149e2..87f911bb7e 100644 --- a/docs/examples/redis/autoscaling/storage/rd-as.yaml +++ b/docs/examples/redis/autoscaling/storage/rd-as.yaml @@ -8,6 +8,7 @@ spec: name: rd-standalone storage: standalone: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/examples/redis/reconfigure/rdops-inline-reconfig.yaml b/docs/examples/redis/reconfigure/rdops-apply-reconfig.yaml similarity index 76% rename from docs/examples/redis/reconfigure/rdops-inline-reconfig.yaml rename to docs/examples/redis/reconfigure/rdops-apply-reconfig.yaml index aeb903f18b..192fb9fe7b 100644 --- a/docs/examples/redis/reconfigure/rdops-inline-reconfig.yaml +++ b/docs/examples/redis/reconfigure/rdops-apply-reconfig.yaml @@ -8,4 +8,6 @@ spec: databaseRef: name: sample-redis configuration: - inlineConfig: maxclients 3000 + applyConfig: + redis.conf: |- + maxclients 3000 diff --git a/docs/guides/elasticsearch/autoscaler/storage/combined/index.md b/docs/guides/elasticsearch/autoscaler/storage/combined/index.md index d6fd448b68..a473463160 100644 --- a/docs/guides/elasticsearch/autoscaler/storage/combined/index.md +++ b/docs/guides/elasticsearch/autoscaler/storage/combined/index.md @@ -135,6 +135,7 @@ spec: name: es-combined storage: node: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/elasticsearch/autoscaler/storage/combined/yamls/es-combined-storage-as.yaml b/docs/guides/elasticsearch/autoscaler/storage/combined/yamls/es-combined-storage-as.yaml index c25a3dbb23..7a821dfe59 100644 --- a/docs/guides/elasticsearch/autoscaler/storage/combined/yamls/es-combined-storage-as.yaml +++ b/docs/guides/elasticsearch/autoscaler/storage/combined/yamls/es-combined-storage-as.yaml @@ -8,6 +8,7 @@ spec: name: es-combined storage: node: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 \ No newline at end of file diff --git a/docs/guides/elasticsearch/autoscaler/storage/topology/index.md b/docs/guides/elasticsearch/autoscaler/storage/topology/index.md index ce295272d3..dc8d0b3b8d 100644 --- a/docs/guides/elasticsearch/autoscaler/storage/topology/index.md +++ b/docs/guides/elasticsearch/autoscaler/storage/topology/index.md @@ -161,6 +161,7 @@ spec: name: es-topology storage: data: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/elasticsearch/autoscaler/storage/topology/yamls/es-topology-storage-as.yaml b/docs/guides/elasticsearch/autoscaler/storage/topology/yamls/es-topology-storage-as.yaml index e0142a927e..17596ac59b 100644 --- a/docs/guides/elasticsearch/autoscaler/storage/topology/yamls/es-topology-storage-as.yaml +++ b/docs/guides/elasticsearch/autoscaler/storage/topology/yamls/es-topology-storage-as.yaml @@ -8,6 +8,7 @@ spec: name: es-topology storage: data: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 \ No newline at end of file diff --git a/docs/guides/elasticsearch/concepts/appbinding/index.md b/docs/guides/elasticsearch/concepts/appbinding/index.md index f5573cbc87..8006070137 100644 --- a/docs/guides/elasticsearch/concepts/appbinding/index.md +++ b/docs/guides/elasticsearch/concepts/appbinding/index.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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/latest/welcome/), the `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database. diff --git a/docs/guides/elasticsearch/concepts/autoscaler/index.md b/docs/guides/elasticsearch/concepts/autoscaler/index.md index 8ddf70d8c6..36db2d26f5 100644 --- a/docs/guides/elasticsearch/concepts/autoscaler/index.md +++ b/docs/guides/elasticsearch/concepts/autoscaler/index.md @@ -53,6 +53,7 @@ spec: resourceDiffPercentage: 10 storage: node: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 @@ -108,6 +109,7 @@ spec: resourceDiffPercentage: 10 storage: data: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/elasticsearch/concepts/elasticsearch-dashboard/index.md b/docs/guides/elasticsearch/concepts/elasticsearch-dashboard/index.md index 0abf4e5ecc..bb4936f169 100644 --- a/docs/guides/elasticsearch/concepts/elasticsearch-dashboard/index.md +++ b/docs/guides/elasticsearch/concepts/elasticsearch-dashboard/index.md @@ -25,7 +25,7 @@ Suppose you have a KubeDB-managed [Elasticsearch](/docs/guides/elasticsearch/con As with all other Kubernetes objects, an `ElasticsearchDashboard` needs `apiVersion`, `kind`, and `metadata` fields. It also needs a `spec` section. ```yaml -apiVersion: dashboard.kubedb.com/v1alpha1 +apiVersion: elasticsearch.kubedb.com/v1alpha1 kind: ElasticsearchDashboard metadata: name: es-cluster-dashboard diff --git a/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md b/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md index b79b1dc456..19a6c6172e 100644 --- a/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md +++ b/docs/guides/elasticsearch/concepts/elasticsearch-ops-request/index.md @@ -284,6 +284,7 @@ All of them refer to [Quantity](https://v1-22.docs.kubernetes.io/docs/reference/ databaseRef: name: es volumeExpansion: + mode: "Online" node: 4Gi ``` @@ -300,6 +301,7 @@ All of them refer to [Quantity](https://v1-22.docs.kubernetes.io/docs/reference/ databaseRef: name: es volumeExpansion: + mode: "Online" master: 2Gi data: 3Gi ingest: 4Gi @@ -318,6 +320,7 @@ All of them refer to [Quantity](https://v1-22.docs.kubernetes.io/docs/reference/ databaseRef: name: es volumeExpansion: + mode: "Online" data: 5Gi ``` diff --git a/docs/guides/elasticsearch/concepts/elasticsearch/index.md b/docs/guides/elasticsearch/concepts/elasticsearch/index.md index 06fa5163a2..bd54c84b31 100644 --- a/docs/guides/elasticsearch/concepts/elasticsearch/index.md +++ b/docs/guides/elasticsearch/concepts/elasticsearch/index.md @@ -887,7 +887,7 @@ It defines the attributes for the health checker. - `spec.healthChecker.failureThreshold` specifies minimum consecutive failures for the healthChecker to be considered failed. - `spec.healthChecker.disableWriteCheck` specifies whether to disable the writeCheck or not. -Know details about KubeDB Health checking from this [blog post](https://blog.byte.builders/post/kubedb-health-checker/). +Know details about KubeDB Health checking from this [blog post](https://appscode.com/blog/post/kubedb-health-checker/). ## Next Steps diff --git a/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/index.md b/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/index.md index ebed2c9bf5..c736bb07a4 100644 --- a/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/index.md +++ b/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/index.md @@ -420,7 +420,7 @@ persistentvolumeclaim/data-es-cluster-master-1 Bound pvc-53fd7683-96a6-4737 ## Deploy ElasticsearchDashboard ```yaml -apiVersion: dashboard.kubedb.com/v1alpha1 +apiVersion: elasticsearch.kubedb.com/v1alpha1 kind: ElasticsearchDashboard metadata: name: es-cluster-dashboard @@ -441,7 +441,7 @@ Let's deploy the above yaml by the following command: ```bash $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/yamls/es-cluster-dashboard.yaml -elasticsearchdashboard.dashboard.kubedb.com/es-cluster-dashboard created +elasticsearchdashboard.elasticsearch.kubedb.com/es-cluster-dashboard created ``` KubeDB will create the necessary resources to deploy the dashboard @@ -450,7 +450,7 @@ KubeDB will create the necessary resources to deploy the dashboard ```bash $ watch kubectl get elasticsearchdashboard -n demo NAME TYPE DATABASE STATUS AGE -es-cluster-dashboard dashboard.kubedb.com/v1alpha1 es-cluster Ready 9m +es-cluster-dashboard elasticsearch.kubedb.com/v1alpha1 es-cluster Ready 9m ``` Here, Elasticsearch Dashboard is in `Ready` state. diff --git a/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/yamls/es-cluster-dashboard.yaml b/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/yamls/es-cluster-dashboard.yaml index e4f6f8c81c..2e7ed29694 100644 --- a/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/yamls/es-cluster-dashboard.yaml +++ b/docs/guides/elasticsearch/elasticsearch-dashboard/kibana/yamls/es-cluster-dashboard.yaml @@ -1,4 +1,4 @@ -apiVersion: dashboard.kubedb.com/v1alpha1 +apiVersion: elasticsearch.kubedb.com/v1alpha1 kind: ElasticsearchDashboard metadata: name: es-cluster-dashboard diff --git a/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/index.md b/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/index.md index 9a06173708..caf739617d 100644 --- a/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/index.md +++ b/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/index.md @@ -408,7 +408,7 @@ persistentvolumeclaim/data-os-cluster-master-1 Bound pvc-37783550-3c3a-4280 ## Deploy ElasticsearchDashboard ```yaml -apiVersion: dashboard.kubedb.com/v1alpha1 +apiVersion: elasticsearch.kubedb.com/v1alpha1 kind: ElasticsearchDashboard metadata: name: os-cluster-dashboard @@ -429,7 +429,7 @@ Let's deploy the above yaml by the following command: ```bash $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch/yamls/os-cluster-dashboard.yaml -elasticsearchdashboard.dashboard.kubedb.com/os-cluster-dashboard created +elasticsearchdashboard.elasticsearch.kubedb.com/os-cluster-dashboard created ``` KubeDB will create the necessary resources to deploy the OpenSearch dashboard according to the above specification. Let’s wait until the dashboard to be ready to use, @@ -437,7 +437,7 @@ KubeDB will create the necessary resources to deploy the OpenSearch dashboard ac ```bash $ watch kubectl get elasticsearchdashboard -n demo NAME TYPE DATABASE STATUS AGE -os-cluster-dashboard dashboard.kubedb.com/v1alpha1 os-cluster Ready 9m +os-cluster-dashboard elasticsearch.kubedb.com/v1alpha1 os-cluster Ready 9m ``` Here, OpenSearch Dashboard is in `Ready` state. diff --git a/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/yamls/os-cluster-dashboard.yaml b/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/yamls/os-cluster-dashboard.yaml index fbe7e8f2ce..d844bffee6 100644 --- a/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/yamls/os-cluster-dashboard.yaml +++ b/docs/guides/elasticsearch/elasticsearch-dashboard/opensearch-dashboards/yamls/os-cluster-dashboard.yaml @@ -1,4 +1,4 @@ -apiVersion: dashboard.kubedb.com/v1alpha1 +apiVersion: elasticsearch.kubedb.com/v1alpha1 kind: ElasticsearchDashboard metadata: name: os-cluster-dashboard diff --git a/docs/guides/kafka/concepts/appbinding.md b/docs/guides/kafka/concepts/appbinding.md index 028fa64b05..41344d365e 100644 --- a/docs/guides/kafka/concepts/appbinding.md +++ b/docs/guides/kafka/concepts/appbinding.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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/latest/welcome/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database. diff --git a/docs/guides/kafka/concepts/catalog.md b/docs/guides/kafka/concepts/catalog.md index 16053dc9b0..353ed094ee 100644 --- a/docs/guides/kafka/concepts/catalog.md +++ b/docs/guides/kafka/concepts/catalog.md @@ -45,6 +45,8 @@ metadata: resourceVersion: "472767" uid: 36a167a3-5218-4e32-b96d-d6b5b0c86125 spec: + connectCluster: + image: ghcr.io/appscode-images/kafka-connect-cluster:3.6.1 db: image: kubedb/kafka-kraft:3.4.0 podSecurityPolicies: diff --git a/docs/guides/kafka/concepts/kafka.md b/docs/guides/kafka/concepts/kafka.md index 419b71429b..beb578b833 100644 --- a/docs/guides/kafka/concepts/kafka.md +++ b/docs/guides/kafka/concepts/kafka.md @@ -386,7 +386,7 @@ It defines the attributes for the health checker. - `spec.healthChecker.failureThreshold` specifies minimum consecutive failures for the healthChecker to be considered failed. - `spec.healthChecker.disableWriteCheck` specifies whether to disable the writeCheck or not. -Know details about KubeDB Health checking from this [blog post](https://blog.byte.builders/post/kubedb-health-checker/). +Know details about KubeDB Health checking from this [blog post](https://appscode.com/blog/post/kubedb-health-checker/). ## Next Steps diff --git a/docs/guides/mariadb/concepts/appbinding/index.md b/docs/guides/mariadb/concepts/appbinding/index.md index 8ace55da25..e4b9ca8e6d 100644 --- a/docs/guides/mariadb/concepts/appbinding/index.md +++ b/docs/guides/mariadb/concepts/appbinding/index.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/mariadb/concepts/opsrequest/index.md b/docs/guides/mariadb/concepts/opsrequest/index.md index d9820517c6..581132b46c 100644 --- a/docs/guides/mariadb/concepts/opsrequest/index.md +++ b/docs/guides/mariadb/concepts/opsrequest/index.md @@ -121,10 +121,11 @@ spec: type: Reconfigure databaseRef: name: sample-mariadb - configuration: - inlineConfig: | - max_connections = 300 - read_buffer_size = 1234567 + configuration: + applyConfig: + my-apply.cnf: |- + max_connections = 300 + read_buffer_size = 1234567 status: conditions: - lastTransitionTime: "2020-08-25T18:22:38Z" @@ -293,7 +294,7 @@ This will expand the volume size of all the mariadb nodes to 2 GB. If you want to reconfigure your Running MariaDB cluster with new custom configuration, you have to specify `spec.configuration` section. This field consists of the following sub-fields: - `configSecret` points to a secret in the same namespace of a MariaDB resource, which contains the new custom configurations. If there are any configSecret set before in the database, this secret will replace it. -- `inlineConfig` contains the new custom config as a string which will be merged with the previous configuration. +- `applyConfig` contains the new custom config as a string which will be merged with the previous configuration. - `removeCustomConfig` reomoves all the custom configs of the MariaDB server. ### spec.tls diff --git a/docs/guides/memcached/concepts/appbinding.md b/docs/guides/memcached/concepts/appbinding.md index fb40cc2b68..ea0e31af57 100644 --- a/docs/guides/memcached/concepts/appbinding.md +++ b/docs/guides/memcached/concepts/appbinding.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/mongodb/autoscaler/storage/replicaset.md b/docs/guides/mongodb/autoscaler/storage/replicaset.md index bf1b23c153..661aa31acd 100644 --- a/docs/guides/mongodb/autoscaler/storage/replicaset.md +++ b/docs/guides/mongodb/autoscaler/storage/replicaset.md @@ -133,6 +133,7 @@ spec: name: mg-rs storage: replicaSet: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/mongodb/autoscaler/storage/sharding.md b/docs/guides/mongodb/autoscaler/storage/sharding.md index 08a1db048a..9498df7bd1 100644 --- a/docs/guides/mongodb/autoscaler/storage/sharding.md +++ b/docs/guides/mongodb/autoscaler/storage/sharding.md @@ -149,6 +149,7 @@ spec: name: mg-sh storage: shard: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/mongodb/autoscaler/storage/standalone.md b/docs/guides/mongodb/autoscaler/storage/standalone.md index 8191dd5385..76945396b9 100644 --- a/docs/guides/mongodb/autoscaler/storage/standalone.md +++ b/docs/guides/mongodb/autoscaler/storage/standalone.md @@ -128,6 +128,7 @@ spec: name: mg-standalone storage: standalone: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/mongodb/concepts/appbinding.md b/docs/guides/mongodb/concepts/appbinding.md index f1f2d5afef..893958b13a 100644 --- a/docs/guides/mongodb/concepts/appbinding.md +++ b/docs/guides/mongodb/concepts/appbinding.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/mongodb/concepts/autoscaler.md b/docs/guides/mongodb/concepts/autoscaler.md index 5315ffadc1..2f2ab179ad 100644 --- a/docs/guides/mongodb/concepts/autoscaler.md +++ b/docs/guides/mongodb/concepts/autoscaler.md @@ -56,6 +56,7 @@ spec: resourceDiffPercentage: 10 storage: standalone: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 @@ -93,6 +94,7 @@ spec: resourceDiffPercentage: 10 storage: replicaSet: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 @@ -154,10 +156,12 @@ spec: resourceDiffPercentage: 10 storage: shard: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 configServer: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/mongodb/concepts/mongodb.md b/docs/guides/mongodb/concepts/mongodb.md index 6ca52b80a3..06773f5003 100644 --- a/docs/guides/mongodb/concepts/mongodb.md +++ b/docs/guides/mongodb/concepts/mongodb.md @@ -631,7 +631,7 @@ It defines the attributes for the health checker. - `spec.healthChecker.failureThreshold` specifies minimum consecutive failures for the healthChecker to be considered failed. - `spec.healthChecker.disableWriteCheck` specifies whether to disable the writeCheck or not. -Know details about KubeDB Health checking from this [blog post](https://blog.byte.builders/post/kubedb-health-checker/). +Know details about KubeDB Health checking from this [blog post](https://appscode.com/blog/post/kubedb-health-checker/). ## Next Steps diff --git a/docs/guides/mongodb/concepts/opsrequest.md b/docs/guides/mongodb/concepts/opsrequest.md index 6ff4b183af..b413e5ab57 100644 --- a/docs/guides/mongodb/concepts/opsrequest.md +++ b/docs/guides/mongodb/concepts/opsrequest.md @@ -231,7 +231,8 @@ spec: name: mg-replicaset configuration: replicaSet: - inlineConfig: | + applyConfig: + mongod.conf: |- net: maxIncomingConnections: 30000 status: @@ -258,17 +259,20 @@ spec: name: mg-sharding configuration: shard: - inlineConfig: | + applyConfig: + mongod.conf: |- net: maxIncomingConnections: 30000 configServer: - inlineConfig: | - net: - maxIncomingConnections: 30000 + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 mongos: - inlineConfig: | - net: - maxIncomingConnections: 30000 + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 status: conditions: - lastTransitionTime: "2020-08-25T18:22:38Z" @@ -293,9 +297,10 @@ spec: name: mg-standalone configuration: standalone: - inlineConfig: | - net: - maxIncomingConnections: 30000 + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 status: conditions: - lastTransitionTime: "2020-08-25T18:22:38Z" @@ -405,6 +410,7 @@ spec: databaseRef: name: mg-replicaset volumeExpansion: + mode: "Online" replicaSet: 2Gi status: conditions: @@ -429,6 +435,7 @@ spec: databaseRef: name: mg-sharding volumeExpansion: + mode: "Online" shard: 2Gi configServer: 2Gi status: @@ -454,6 +461,7 @@ spec: databaseRef: name: mg-standalone volumeExpansion: + mode: "Online" standalone: 2Gi status: conditions: @@ -649,10 +657,9 @@ If you want to reconfigure your Running MongoDB cluster or different components All of them has the following sub-fields: - `configSecret` points to a secret in the same namespace of a MongoDB resource, which contains the new custom configurations. If there are any configSecret set before in the database, this secret will replace it. -- `inlineConfig` contains the new custom config as a string which will be merged with the previous configuration. -> Note: You can use `inlineConfig` only for `mongod.conf` configurations. This field is deprecated & will be removed in some future KubeDB release. +- `applyConfig` contains the new custom config as a string which will be merged with the previous configuration. -- `applyConfig` is the replacement of `inlineConfig`. It is a map where key supports 3 values, namely `mongod.conf`, `replicaset.json`, `configuration.js`. And value represents the corresponding configurations. +- `applyConfig` is a map where key supports 3 values, namely `mongod.conf`, `replicaset.json`, `configuration.js`. And value represents the corresponding configurations. For your information, replicaset.json is used to modify replica set configurations, which we see in the output of `rs.config()`. And `configurarion.js` is used to apply a js script to configure mongodb at runtime. KubeDB provisioner operator applies these two directly while reconciling. diff --git a/docs/guides/mongodb/pitr/pitr.md b/docs/guides/mongodb/pitr/pitr.md index 34c79edbe2..7365d0396d 100644 --- a/docs/guides/mongodb/pitr/pitr.md +++ b/docs/guides/mongodb/pitr/pitr.md @@ -52,7 +52,7 @@ spec: gcs: bucket: kubestash-qa prefix: mg - secret: gcs-secret + secretName: gcs-secret usagePolicy: allowedNamespaces: from: All diff --git a/docs/guides/mongodb/reconfigure/replicaset.md b/docs/guides/mongodb/reconfigure/replicaset.md index f9f8051421..71ddb855fa 100644 --- a/docs/guides/mongodb/reconfigure/replicaset.md +++ b/docs/guides/mongodb/reconfigure/replicaset.md @@ -408,19 +408,19 @@ $ kubectl exec -n demo mg-replicaset-0 -- mongo admin -u root -p nrKuxni0wDSMr As we can see from the configuration of ready mongodb, the value of `maxIncomingConnections` has been changed from `10000` to `20000`. So the reconfiguration of the database is successful. -### Reconfigure using inline config +### Reconfigure using apply config -Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `inlineConfig` field of the `MongoDBOpsRequest`. This will merge the new config in the existing secret. +Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `applyConfig` field of the `MongoDBOpsRequest`. This will merge the new config in the existing secret. #### Create MongoDBOpsRequest -Now, we will use the new configuration in the `inlineConfig` field in the `MongoDBOpsRequest` CR. The `MongoDBOpsRequest` yaml is given below, +Now, we will use the new configuration in the `applyConfig` field in the `MongoDBOpsRequest` CR. The `MongoDBOpsRequest` yaml is given below, ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: MongoDBOpsRequest metadata: - name: mops-reconfigure-inline-replicaset + name: mops-reconfigure-apply-replicaset namespace: demo spec: type: Reconfigure @@ -428,7 +428,8 @@ spec: name: mg-replicaset configuration: replicaSet: - inlineConfig: | + applyConfig: + mongod.conf: |- net: maxIncomingConnections: 30000 readinessCriteria: @@ -440,17 +441,17 @@ spec: Here, -- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-inline-replicaset` database. +- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-apply-replicaset` database. - `spec.type` specifies that we are performing `Reconfigure` on our database. -- `spec.configuration.replicaSet.inlineConfig` specifies the new configuration that will be merged in the existing secret. +- `spec.configuration.replicaSet.applyConfig` specifies the new configuration that will be merged in the existing secret. - `spec.customConfig.arbiter.configSecret.name` could also be specified with a config-secret. - Have a look [here](/docs/guides/mongodb/concepts/opsrequest.md#specreadinesscriteria) on the respective sections to understand the `readinessCriteria`, `timeout` & `apply` fields. Let's create the `MongoDBOpsRequest` CR we have shown above, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-replicaset.yaml -mongodbopsrequest.ops.kubedb.com/mops-reconfigure-inline-replicaset created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-replicaset.yaml +mongodbopsrequest.ops.kubedb.com/mops-reconfigure-apply-replicaset created ``` #### Verify the new configuration is working @@ -463,14 +464,14 @@ Let's wait for `MongoDBOpsRequest` to be `Successful`. Run the following comman $ watch kubectl get mongodbopsrequest -n demo Every 2.0s: kubectl get mongodbopsrequest -n demo NAME TYPE STATUS AGE -mops-reconfigure-inline-replicaset Reconfigure Successful 109s +mops-reconfigure-apply-replicaset Reconfigure Successful 109s ``` We can see from the above output that the `MongoDBOpsRequest` has succeeded. If we describe the `MongoDBOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. ```bash -$ kubectl describe mongodbopsrequest -n demo mops-reconfigure-inline-replicaset -Name: mops-reconfigure-inline-replicaset +$ kubectl describe mongodbopsrequest -n demo mops-reconfigure-apply-replicaset +Name: mops-reconfigure-apply-replicaset Namespace: demo Labels: Annotations: @@ -494,7 +495,7 @@ Metadata: .: f:replicaSet: .: - f:inlineConfig: + f:applyConfig: f:databaseRef: .: f:name: @@ -529,13 +530,13 @@ Metadata: Operation: Update Time: 2021-03-02T07:09:39Z Resource Version: 31005 - Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mongodbopsrequests/mops-reconfigure-inline-replicaset + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mongodbopsrequests/mops-reconfigure-apply-replicaset UID: 0137442b-1b04-43ed-8de7-ecd913b44065 Spec: Apply: IfReady Configuration: Replica Set: - Inline Config: net: + Apply Config: net: maxIncomingConnections: 30000 Database Ref: @@ -631,7 +632,7 @@ $ kubectl exec -n demo mg-replicaset-0 -- mongo admin -u root -p nrKuxni0wDSMr } ``` -As we can see from the configuration of ready mongodb, the value of `maxIncomingConnections` has been changed from `20000` to `30000`. So the reconfiguration of the database using the `inlineConfig` field is successful. +As we can see from the configuration of ready mongodb, the value of `maxIncomingConnections` has been changed from `20000` to `30000`. So the reconfiguration of the database using the `applyConfig` field is successful. ## Cleaning Up @@ -640,5 +641,5 @@ To clean up the Kubernetes resources created by this tutorial, run: ```bash kubectl delete mg -n demo mg-replicaset -kubectl delete mongodbopsrequest -n demo mops-reconfigure-replicaset mops-reconfigure-inline-replicaset +kubectl delete mongodbopsrequest -n demo mops-reconfigure-replicaset mops-reconfigure-apply-replicaset ``` \ No newline at end of file diff --git a/docs/guides/mongodb/reconfigure/sharding.md b/docs/guides/mongodb/reconfigure/sharding.md index 532aede853..1df25019ab 100644 --- a/docs/guides/mongodb/reconfigure/sharding.md +++ b/docs/guides/mongodb/reconfigure/sharding.md @@ -287,9 +287,9 @@ $ kubectl exec -n demo mg-sharding-shard0-0 -- mongo admin -u root -p Dv8F55zV As we can see from the configuration of ready mongodb, the value of `maxIncomingConnections` has been changed from `10000` to `20000` in all type of nodes. So the reconfiguration of the database is successful. -### Reconfigure using inline config +### Reconfigure using apply config -Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `inlineConfig` field of the `MongoDBOpsRequest`. This will merge the new config in the existing secret. +Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `applyConfig` field of the `MongoDBOpsRequest`. This will merge the new config in the existing secret. #### Create MongoDBOpsRequest @@ -299,7 +299,7 @@ Now, we will use the new configuration in the `data` field in the `MongoDBOpsReq apiVersion: ops.kubedb.com/v1alpha1 kind: MongoDBOpsRequest metadata: - name: mops-reconfigure-inline-shard + name: mops-reconfigure-apply-shard namespace: demo spec: type: Reconfigure @@ -307,15 +307,18 @@ spec: name: mg-sharding configuration: shard: - inlineConfig: | + applyConfig: + mongod.conf: |- net: maxIncomingConnections: 30000 configServer: - inlineConfig: | + applyConfig: + mongod.conf: |- net: maxIncomingConnections: 30000 mongos: - inlineConfig: | + applyConfig: + mongod.conf: |- net: maxIncomingConnections: 30000 readinessCriteria: @@ -327,11 +330,11 @@ spec: Here, -- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-inline-shard` database. +- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-apply-shard` database. - `spec.type` specifies that we are performing `Reconfigure` on our database. -- `spec.configuration.shard.inlineConfig` specifies the new configuration that will be merged in the existing secret for shard nodes. -- `spec.configuration.configServer.inlineConfig` specifies the new configuration that will be merged in the existing secret for configServer nodes. -- `spec.configuration.mongos.inlineConfig` specifies the new configuration that will be merged in the existing secret for mongos nodes. +- `spec.configuration.shard.applyConfig` specifies the new configuration that will be merged in the existing secret for shard nodes. +- `spec.configuration.configServer.applyConfig` specifies the new configuration that will be merged in the existing secret for configServer nodes. +- `spec.configuration.mongos.applyConfig` specifies the new configuration that will be merged in the existing secret for mongos nodes. - `spec.customConfig.arbiter.configSecret.name` could also be specified with a config-secret. - Have a look [here](/docs/guides/mongodb/concepts/opsrequest.md#specreadinesscriteria) on the respective sections to understand the `readinessCriteria`, `timeout` & `apply` fields. @@ -340,8 +343,8 @@ Here, Let's create the `MongoDBOpsRequest` CR we have shown above, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-shard.yaml -mongodbopsrequest.ops.kubedb.com/mops-reconfigure-inline-shard created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-shard.yaml +mongodbopsrequest.ops.kubedb.com/mops-reconfigure-apply-shard created ``` #### Verify the new configuration is working @@ -354,14 +357,14 @@ Let's wait for `MongoDBOpsRequest` to be `Successful`. Run the following comman $ watch kubectl get mongodbopsrequest -n demo Every 2.0s: kubectl get mongodbopsrequest -n demo NAME TYPE STATUS AGE -mops-reconfigure-inline-shard Reconfigure Successful 3m24s +mops-reconfigure-apply-shard Reconfigure Successful 3m24s ``` We can see from the above output that the `MongoDBOpsRequest` has succeeded. If we describe the `MongoDBOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. ```bash -$ kubectl describe mongodbopsrequest -n demo mops-reconfigure-inline-shard -Name: mops-reconfigure-inline-shard +$ kubectl describe mongodbopsrequest -n demo mops-reconfigure-apply-shard +Name: mops-reconfigure-apply-shard Namespace: demo Labels: Annotations: @@ -448,21 +451,21 @@ Metadata: Operation: Update Time: 2021-03-02T13:08:25Z Resource Version: 103635 - Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mongodbopsrequests/mops-reconfigure-inline-shard + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mongodbopsrequests/mops-reconfigure-apply-shard UID: ab454bcb-164c-4fa2-9eaa-dd47c60fe874 Spec: Apply: IfReady Configuration: Config Server: - Inline Config: net: + Apply Config: net: maxIncomingConnections: 30000 Mongos: - Inline Config: net: + Apply Config: net: maxIncomingConnections: 30000 Shard: - Inline Config: net: + Apply Config: net: maxIncomingConnections: 30000 Database Ref: @@ -564,5 +567,5 @@ To clean up the Kubernetes resources created by this tutorial, run: ```bash kubectl delete mg -n demo mg-sharding -kubectl delete mongodbopsrequest -n demo mops-reconfigure-shard mops-reconfigure-inline-shard +kubectl delete mongodbopsrequest -n demo mops-reconfigure-shard mops-reconfigure-apply-shard ``` \ No newline at end of file diff --git a/docs/guides/mongodb/reconfigure/standalone.md b/docs/guides/mongodb/reconfigure/standalone.md index d9698a3b49..82b380e240 100644 --- a/docs/guides/mongodb/reconfigure/standalone.md +++ b/docs/guides/mongodb/reconfigure/standalone.md @@ -371,9 +371,9 @@ $ kubectl exec -n demo mg-standalone-0 -- mongo admin -u root -p m6lXjZugrC4VE As we can see from the configuration of running mongodb, the value of `maxIncomingConnections` has been changed from `10000` to `20000`. So the reconfiguration of the database is successful. -### Reconfigure using inline config +### Reconfigure using apply config -Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `inlineConfig` field of the `MongoDBOpsRequest`. This will merge the new config in the existing secret. +Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `applyConfig` field of the `MongoDBOpsRequest`. This will merge the new config in the existing secret. #### Create MongoDBOpsRequest @@ -383,7 +383,7 @@ Now, we will use the new configuration in the `data` field in the `MongoDBOpsReq apiVersion: ops.kubedb.com/v1alpha1 kind: MongoDBOpsRequest metadata: - name: mops-reconfigure-inline-standalone + name: mops-reconfigure-apply-standalone namespace: demo spec: type: Reconfigure @@ -391,9 +391,10 @@ spec: name: mg-standalone configuration: standalone: - inlineConfig: | - net: - maxIncomingConnections: 30000 + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 readinessCriteria: oplogMaxLagSeconds: 20 objectsCountDiffPercentage: 10 @@ -403,15 +404,15 @@ spec: Here, -- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-inline-standalone` database. +- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-apply-standalone` database. - `spec.type` specifies that we are performing `Reconfigure` on our database. -- `spec.configuration.standalone.inlineConfig` specifies the new configuration that will be merged in the existing secret. +- `spec.configuration.standalone.applyConfig` specifies the new configuration that will be merged in the existing secret. Let's create the `MongoDBOpsRequest` CR we have shown above, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/reconfigure/mops-reconfigure-inline-standalone.yaml -mongodbopsrequest.ops.kubedb.com/mops-reconfigure-inline-standalone created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mongodb/reconfigure/mops-reconfigure-apply-standalone.yaml +mongodbopsrequest.ops.kubedb.com/mops-reconfigure-apply-standalone created ``` #### Verify the new configuration is working @@ -424,14 +425,14 @@ Let's wait for `MongoDBOpsRequest` to be `Successful`. Run the following comman $ watch kubectl get mongodbopsrequest -n demo Every 2.0s: kubectl get mongodbopsrequest -n demo NAME TYPE STATUS AGE -mops-reconfigure-inline-standalone Reconfigure Successful 38s +mops-reconfigure-apply-standalone Reconfigure Successful 38s ``` We can see from the above output that the `MongoDBOpsRequest` has succeeded. If we describe the `MongoDBOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. ```bash -$ kubectl describe mongodbopsrequest -n demo mops-reconfigure-inline-standalone -Name: mops-reconfigure-inline-standalone +$ kubectl describe mongodbopsrequest -n demo mops-reconfigure-apply-standalone +Name: mops-reconfigure-apply-standalone Namespace: demo Labels: Annotations: @@ -455,7 +456,7 @@ Metadata: .: f:standalone: .: - f:inlineConfig: + f:applyConfig: f:databaseRef: .: f:name: @@ -490,13 +491,13 @@ Metadata: Operation: Update Time: 2021-03-02T15:09:13Z Resource Version: 126782 - Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mongodbopsrequests/mops-reconfigure-inline-standalone + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mongodbopsrequests/mops-reconfigure-apply-standalone UID: 33eea32f-e2af-4e36-b612-c528549e3d65 Spec: Apply: IfReady Configuration: Standalone: - Inline Config: net: + Apply Config: net: maxIncomingConnections: 30000 Database Ref: @@ -576,7 +577,7 @@ $ kubectl exec -n demo mg-standalone-0 -- mongo admin -u root -p m6lXjZugrC4VE } ``` -As we can see from the configuration of running mongodb, the value of `maxIncomingConnections` has been changed from `20000` to `30000`. So the reconfiguration of the database using the `inlineConfig` field is successful. +As we can see from the configuration of running mongodb, the value of `maxIncomingConnections` has been changed from `20000` to `30000`. So the reconfiguration of the database using the `applyConfig` field is successful. ## Cleaning Up @@ -585,5 +586,5 @@ To clean up the Kubernetes resources created by this tutorial, run: ```bash kubectl delete mg -n demo mg-standalone -kubectl delete mongodbopsrequest -n demo mops-reconfigure-standalone mops-reconfigure-inline-standalone +kubectl delete mongodbopsrequest -n demo mops-reconfigure-standalone mops-reconfigure-apply-standalone ``` \ No newline at end of file diff --git a/docs/guides/mongodb/volume-expansion/replicaset.md b/docs/guides/mongodb/volume-expansion/replicaset.md index 588ff3dc61..a7a0e65ba7 100644 --- a/docs/guides/mongodb/volume-expansion/replicaset.md +++ b/docs/guides/mongodb/volume-expansion/replicaset.md @@ -133,6 +133,7 @@ spec: databaseRef: name: mg-replicaset volumeExpansion: + mode: "Online" replicaSet: 2Gi ``` diff --git a/docs/guides/mongodb/volume-expansion/sharding.md b/docs/guides/mongodb/volume-expansion/sharding.md index 98318e4df2..ed8fb8703a 100644 --- a/docs/guides/mongodb/volume-expansion/sharding.md +++ b/docs/guides/mongodb/volume-expansion/sharding.md @@ -148,6 +148,7 @@ spec: databaseRef: name: mg-sharding volumeExpansion: + mode: "Online" shard: 2Gi configServer: 2Gi ``` diff --git a/docs/guides/mongodb/volume-expansion/standalone.md b/docs/guides/mongodb/volume-expansion/standalone.md index b71dae6fe6..ea7224b947 100644 --- a/docs/guides/mongodb/volume-expansion/standalone.md +++ b/docs/guides/mongodb/volume-expansion/standalone.md @@ -127,6 +127,7 @@ spec: databaseRef: name: mg-standalone volumeExpansion: + mode: "Online" standalone: 2Gi ``` diff --git a/docs/guides/mysql/concepts/appbinding/index.md b/docs/guides/mysql/concepts/appbinding/index.md index c99abb8825..c2de27c995 100644 --- a/docs/guides/mysql/concepts/appbinding/index.md +++ b/docs/guides/mysql/concepts/appbinding/index.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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/), `AppBinding` object will be created automatically for it. Otherwise, you have to create an `AppBinding` object manually pointing to your desired database. diff --git a/docs/guides/mysql/pitr/archiver.md b/docs/guides/mysql/pitr/archiver.md index 959ddab73d..981bd36eef 100644 --- a/docs/guides/mysql/pitr/archiver.md +++ b/docs/guides/mysql/pitr/archiver.md @@ -56,7 +56,7 @@ spec: endpoint: https://ap-south-1.linodeobjects.com region: ap-south-1 prefix: backup - secret: storage + secretName: storage usagePolicy: allowedNamespaces: from: All diff --git a/docs/guides/mysql/pitr/yamls/backupstorage.yaml b/docs/guides/mysql/pitr/yamls/backupstorage.yaml index 6747e4338a..686860f4b0 100644 --- a/docs/guides/mysql/pitr/yamls/backupstorage.yaml +++ b/docs/guides/mysql/pitr/yamls/backupstorage.yaml @@ -11,7 +11,7 @@ spec: endpoint: https://ap-south-1.linodeobjects.com region: ap-south-1 prefix: backup - secret: storage + secretName: storage usagePolicy: allowedNamespaces: from: All diff --git a/docs/guides/percona-xtradb/concepts/appbinding/index.md b/docs/guides/percona-xtradb/concepts/appbinding/index.md index c55e61011b..4d4fdf9ee6 100644 --- a/docs/guides/percona-xtradb/concepts/appbinding/index.md +++ b/docs/guides/percona-xtradb/concepts/appbinding/index.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/percona-xtradb/concepts/opsrequest/index.md b/docs/guides/percona-xtradb/concepts/opsrequest/index.md index a673968fa6..81933d8185 100644 --- a/docs/guides/percona-xtradb/concepts/opsrequest/index.md +++ b/docs/guides/percona-xtradb/concepts/opsrequest/index.md @@ -122,9 +122,10 @@ spec: databaseRef: name: sample-pxc configuration: - inlineConfig: | - max_connections = 300 - read_buffer_size = 1234567 + applyConfig: + my-apply.cnf: |- + max_connections = 300 + read_buffer_size = 1234567 status: conditions: - lastTransitionTime: "2020-08-25T18:22:38Z" @@ -293,7 +294,7 @@ This will expand the volume size of all the perconaxtradb nodes to 2 GB. If you want to reconfigure your Running PerconaXtraDB cluster with new custom configuration, you have to specify `spec.configuration` section. This field consists of the following sub-fields: - `configSecret` points to a secret in the same namespace of a PerconaXtraDB resource, which contains the new custom configurations. If there are any configSecret set before in the database, this secret will replace it. -- `inlineConfig` contains the new custom config as a string which will be merged with the previous configuration. +- `applyConfig` contains the new custom config as a string which will be merged with the previous configuration. - `removeCustomConfig` reomoves all the custom configs of the PerconaXtraDB server. ### spec.tls diff --git a/docs/guides/pgbouncer/concepts/appbinding.md b/docs/guides/pgbouncer/concepts/appbinding.md index 4de6f556a6..bde708d6ff 100644 --- a/docs/guides/pgbouncer/concepts/appbinding.md +++ b/docs/guides/pgbouncer/concepts/appbinding.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/postgres/concepts/appbinding.md b/docs/guides/postgres/concepts/appbinding.md index c69bc8e1c7..bc02784e08 100644 --- a/docs/guides/postgres/concepts/appbinding.md +++ b/docs/guides/postgres/concepts/appbinding.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/postgres/pitr/archiver.md b/docs/guides/postgres/pitr/archiver.md index ec34e9eacc..eee80e940a 100644 --- a/docs/guides/postgres/pitr/archiver.md +++ b/docs/guides/postgres/pitr/archiver.md @@ -56,7 +56,7 @@ spec: endpoint: https://ap-south-1.linodeobjects.com region: ap-south-1 prefix: backup - secret: storage + secretName: storage usagePolicy: allowedNamespaces: from: All diff --git a/docs/guides/postgres/pitr/yamls/backupstorage.yaml b/docs/guides/postgres/pitr/yamls/backupstorage.yaml index 6747e4338a..686860f4b0 100644 --- a/docs/guides/postgres/pitr/yamls/backupstorage.yaml +++ b/docs/guides/postgres/pitr/yamls/backupstorage.yaml @@ -11,7 +11,7 @@ spec: endpoint: https://ap-south-1.linodeobjects.com region: ap-south-1 prefix: backup - secret: storage + secretName: storage usagePolicy: allowedNamespaces: from: All diff --git a/docs/guides/proxysql/concepts/appbinding/index.md b/docs/guides/proxysql/concepts/appbinding/index.md index 58e73d55b8..662b1ce6db 100644 --- a/docs/guides/proxysql/concepts/appbinding/index.md +++ b/docs/guides/proxysql/concepts/appbinding/index.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/redis/autoscaler/storage/redis.md b/docs/guides/redis/autoscaler/storage/redis.md index 4485f193ae..0b7f3813c7 100644 --- a/docs/guides/redis/autoscaler/storage/redis.md +++ b/docs/guides/redis/autoscaler/storage/redis.md @@ -131,6 +131,7 @@ spec: name: rd-standalone storage: standalone: + expansionMode: "Online" trigger: "On" usageThreshold: 60 scalingThreshold: 50 diff --git a/docs/guides/redis/concepts/appbinding.md b/docs/guides/redis/concepts/appbinding.md index a85a1b15a1..8280323679 100644 --- a/docs/guides/redis/concepts/appbinding.md +++ b/docs/guides/redis/concepts/appbinding.md @@ -16,7 +16,7 @@ section_menu_id: guides ## What is AppBinding -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://blog.byte.builders/post/the-case-for-appbinding). +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. diff --git a/docs/guides/redis/concepts/autoscaler.md b/docs/guides/redis/concepts/autoscaler.md index 3eed8db5c5..71186cbd0a 100644 --- a/docs/guides/redis/concepts/autoscaler.md +++ b/docs/guides/redis/concepts/autoscaler.md @@ -53,6 +53,7 @@ spec: resourceDiffPercentage: 10 storage: standalone: + expansionMode: "Online" trigger: "On" usageThreshold: 25 scalingThreshold: 20 diff --git a/docs/guides/redis/concepts/redis.md b/docs/guides/redis/concepts/redis.md index 7473ebe549..48177dbe15 100644 --- a/docs/guides/redis/concepts/redis.md +++ b/docs/guides/redis/concepts/redis.md @@ -394,7 +394,7 @@ It defines the attributes for the health checker. - `spec.healthChecker.failureThreshold` specifies minimum consecutive failures for the healthChecker to be considered failed. - `spec.healthChecker.disableWriteCheck` specifies whether to disable the writeCheck or not. -Know details about KubeDB Health checking from this [blog post](https://blog.byte.builders/post/kubedb-health-checker/). +Know details about KubeDB Health checking from this [blog post](https://appscode.com/blog/post/kubedb-health-checker/). ## Next Steps diff --git a/docs/guides/redis/concepts/redissentinel.md b/docs/guides/redis/concepts/redissentinel.md index 4751fef836..9efc9322eb 100644 --- a/docs/guides/redis/concepts/redissentinel.md +++ b/docs/guides/redis/concepts/redissentinel.md @@ -365,7 +365,7 @@ It defines the attributes for the health checker. - `spec.healthChecker.failureThreshold` specifies minimum consecutive failures for the healthChecker to be considered failed. - `spec.healthChecker.disableWriteCheck` specifies whether to disable the writeCheck or not. -Know details about KubeDB Health checking from this [blog post](https://blog.byte.builders/post/kubedb-health-checker/). +Know details about KubeDB Health checking from this [blog post](https://appscode.com/blog/post/kubedb-health-checker/). ## Sample Redis instace A yaml for a sample Redis instance that can be monitored by this RedisSentinel instance is given below diff --git a/docs/guides/redis/reconfigure/redis.md b/docs/guides/redis/reconfigure/redis.md index 8d21923d46..9afbbf02f6 100644 --- a/docs/guides/redis/reconfigure/redis.md +++ b/docs/guides/redis/reconfigure/redis.md @@ -259,9 +259,9 @@ maxclients As we can see from the configuration of running redis, the value of `maxclients` has been changed from `500` to `20000`. So the reconfiguration of the database is successful. -### Reconfigure using inline config +### Reconfigure using apply config -Now we will reconfigure this database again to set `maxclients` to `3000`. This time we won't use a new secret. We will use the `inlineConfig` field of the `RedisOpsRequest`. This will merge the new config in the existing secret. +Now we will reconfigure this database again to set `maxclients` to `3000`. This time we won't use a new secret. We will use the `applyConfig` field of the `RedisOpsRequest`. This will merge the new config in the existing secret. #### Create RedisOpsRequest @@ -271,27 +271,29 @@ Now, we will use the new configuration in the `data` field in the `RedisOpsReque apiVersion: ops.kubedb.com/v1alpha1 kind: RedisOpsRequest metadata: - name: rdops-inline-reconfig + name: rdops-apply-reconfig namespace: demo spec: type: Reconfigure databaseRef: name: sample-redis configuration: - inlineConfig: maxclients 3000 + applyConfig: + redis.conf: |- + maxclients 3000 ``` Here, - `spec.databaseRef.name` specifies that we are reconfiguring `sample-redis` database. - `spec.type` specifies that we are performing `Reconfigure` on our database. -- `spec.configuration.inlineConfig` specifies the new configuration that will be merged in the existing secret. +- `spec.configuration.applyConfig` specifies the new configuration that will be merged in the existing secret. Let's create the `RedisOpsRequest` CR we have shown above, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/redis/reconfigure/rdops-inline-reconfig.yaml -redisopsrequest.ops.kubedb.com/rdops-inline-reconfig created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/redis/reconfigure/rdops-apply-reconfig.yaml +redisopsrequest.ops.kubedb.com/rdops-apply-reconfig created ``` #### Verify the new configuration is working @@ -304,14 +306,14 @@ Let's wait for `RedisOpsRequest` to be `Successful`. Run the following command $ watch kubectl get redisopsrequest -n demo Every 2.0s: kubectl get redisopsrequest -n demo NAME TYPE STATUS AGE -rdops-inline-reconfig Reconfigure Successful 38s +rdops-apply-reconfig Reconfigure Successful 38s ``` We can see from the above output that the `RedisOpsRequest` has succeeded. If we describe the `RedisOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. ```bash -$ kubectl describe redisopsrequest -n demo rdops-inline-reconfig -Name: rdops-inline-reconfig +$ kubectl describe redisopsrequest -n demo rdops-apply-reconfig +Name: rdops-apply-reconfig Namespace: demo Labels: Annotations: @@ -325,7 +327,7 @@ Metadata: Spec: Apply: IfReady Configuration: - Inline Config: maxclients 3000 + Apply Config: maxclients 3000 Database Ref: Name: sample-redis Type: Reconfigure @@ -381,7 +383,7 @@ maxclients 3000 ``` -As we can see from the configuration of running redis, the value of `maxclients` has been changed from `2000` to `3000`. So the reconfiguration of the database using the `inlineConfig` field is successful. +As we can see from the configuration of running redis, the value of `maxclients` has been changed from `2000` to `3000`. So the reconfiguration of the database using the `applyConfig` field is successful. ## Cleaning Up @@ -390,5 +392,5 @@ To clean up the Kubernetes resources created by this tutorial, run: ```bash kubectl delete rd -n demo sample-redis -kubectl delete redisopsrequest -n demo rdops-reconfigure rdops-inline-reconfig +kubectl delete redisopsrequest -n demo rdops-reconfigure rdops-apply-reconfig ``` \ No newline at end of file