fix

kubedb · Oct 14, 2018 · f5537b6 · f5537b6
1 parent 452288d
commit f5537b6
Show file tree

Hide file tree

Showing 14 changed files with 36 additions and 29 deletions.
diff --git a/docs/concepts/catalog/elasticsearch.md b/docs/concepts/catalog/elasticsearch.md
@@ -57,7 +57,7 @@ We modify original Elasticsearch docker image to support additional features lik
 
 ### spec.deprecated
 
-`spec.deprecated` is an optional field that specifies whether the docker images specified here is supported by the current KubeDB operator. For example, we have modified `kubedb/elasticsearch:6.2.4` docker image to support custom configuration and re-tagged as `kubedb/elasticsearch:6.2.4-v1`. Now, KubeDB `0.9.0` supports providing custom configuration which required `kubedb/elasticsearch:6.2.4-v1` docker image. So, we have marked `kubedb/elasticsearch:6.2.4` version has been marked deprecated in KubeDB `0.9.0`.
+`spec.deprecated` is an optional field that specifies whether the docker images specified here is supported by the current KubeDB operator. For example, we have modified `kubedb/elasticsearch:6.2.4` docker image to support custom configuration and re-tagged as `kubedb/elasticsearch:6.2.4-v1`. Now, KubeDB `0.9.0` supports providing custom configuration which required `kubedb/elasticsearch:6.2.4-v1` docker image. So, we have marked `kubedb/elasticsearch:6.2.4` as deprecated in KubeDB `0.9.0`.
 
 The default value of this field is `false`. If `spec.depcrecated` is set `true`, KubeDB operator will not create the database and other respective resources for this version.
 

diff --git a/docs/concepts/catalog/postgres.md b/docs/concepts/catalog/postgres.md
@@ -25,7 +25,7 @@ Using a separate crd for specifying respective docker images allows us to modify
 As with all other Kubernetes objects, a PostgresVersion needs `apiVersion`, `kind`, and `metadata` fields. It also needs a `.spec` section.
 
 ```yaml
-apiVersion: kubedb.com/v1alpha1
+apiVersion: catalog.kubedb.com/v1alpha1
 kind: PostgresVersion
 metadata:
   name: "10.2-v1"
@@ -49,15 +49,15 @@ spec:
 We follow this convention for naming PostgresVersion crd:
 - Name format: `{Original PostgreSQL image version}-{modification tag}`
 
-We modify original PostgreSQL docker image to support additional features like WAL archiving, clustering etc. and re-tag the image with v1,v2 etc. modification tag. An image with higher modification tag will have more feature than the images with lower modification tag. Hence, it is recommended to use PostgresVersion crd with highest modification tag to enjoy latest features.
+We modify original PostgreSQL docker image to support additional features like WAL archiving, clustering etc. and re-tag the image with v1, v2 etc. modification tag. An image with higher modification tag will have more feature than the images with lower modification tag. Hence, it is recommended to use PostgresVersion crd with highest modification tag to take advantage of the latest features.
 
 ### spec.version
 
 `spec.version` is a required field that specifies the original version of PostgreSQL database that has been used to build the docker image specified in `spec.db.image` field.
 
 ### spec.deprecated
 
-`spec.deprecated` is an optional field that specifies whether the docker images specified here is supported by the current KubeDB operator. For example, we have modified `kubedb/postgres:10.2` docker image to support custom configuration and re-tagged as `kubedb/postgres:10.2-v1`. Now, KubeDB `0.9.0` supports providing custom configuration which required `kubedb/postgres:10.2-v1` docker image. So, we have marked `kubedb/postgres:10.2` as deprecated for KubeDB `0.9.0`.
+`spec.deprecated` is an optional field that specifies whether the docker images specified here is supported by the current KubeDB operator. For example, we have modified `kubedb/postgres:10.2` docker image to support custom configuration and re-tagged as `kubedb/postgres:10.2-v1`. Now, KubeDB `0.9.0` supports providing custom configuration which required `kubedb/postgres:10.2-v1` docker image. So, we have marked `kubedb/postgres:10.2` as deprecated in KubeDB `0.9.0`.
 
 The default value of this field is `false`. If `spec.depcrecated` is set `true`, KubeDB operator will not create the database and other respective resources for this version.
 

diff --git a/docs/concepts/databases/elasticsearch.md b/docs/concepts/databases/elasticsearch.md
@@ -293,8 +293,10 @@ You have to specify following fields to take periodic backup of your Elasticsear
 
 You can also specify a template for pod of backup job through `spec.backupSchedule.podTemplate`. KubeDB will use the information you have provided in `podTemplate` to create the backup job. KubeDB accept following fields to set in `spec.backupSchedule.podTemplate`:
 
-- annotations (pod's annotation)
-- controller.annotations (job's annotation)
+- metadata
+  - annotations (pod's annotation)
+- controller
+  - annotations (job's annotation)
 - spec:
   - args
   - env
@@ -329,8 +331,10 @@ KubeDB allows providing a template for database pod through `spec.podTemplate`.
 
 KubeDB accept following fields to set in `spec.podTemplate:`
 
-- annotations (pod's annotation)
-- controller.annotations (statefulset's annotation)
+- metadata
+  - annotations (pod's annotation)
+- controller
+  - annotations (statefulset's annotation)
 - spec:
   - env
   - resources

diff --git a/docs/concepts/databases/postgres.md b/docs/concepts/databases/postgres.md
@@ -33,7 +33,7 @@ metadata:
 spec:
   version: "9.6-v1"
   replicas: 2
-  standbyMode: hot
+  standbyMode: Hot
   streamingMode: asynchronous
   archiver:
     storage:
@@ -119,7 +119,7 @@ spec:
 
 ### spec.standbyMode
 
-`spec.standby` is an optional field that specifies the standby mode (_warm / hot_) to use for standby replicas. In **hot standby** mode, standby replicas can accept connection and run read-only queries. In **warm standby** mode, standby replicas can't accept connection and only used for replication purpose.
+`spec.standby` is an optional field that specifies the standby mode (_Warm / Hot_) to use for standby replicas. In **hot standby** mode, standby replicas can accept connection and run read-only queries. In **warm standby** mode, standby replicas can't accept connection and only used for replication purpose.
 
 ### spec.streamingMode
 
@@ -283,8 +283,10 @@ You have to specify following fields to take periodic backup of your Postgres da
 
 You can also specify a template for pod of backup job through `spec.backupSchedule.podTemplate`. KubeDB will use the information you have provided in `podTemplate` to create the backup job. KubeDB accept following fields to set in `spec.backupSchedule.podTemplate`:
 
-- annotations (pod's annotation)
-- controller.annotations (job's annotation)
+- metadata
+  - annotations (pod's annotation)
+- controller
+  - annotations (job's annotation)
 - spec:
   - args
   - env
@@ -319,8 +321,10 @@ KubeDB allows providing a template for database pod through `spec.podTemplate`.
 
 KubeDB accept following fields to set in `spec.podTemplate:`
 
-- annotations (pod's annotation)
-- controller.annotations (statefulset's annotation)
+- metadata
+  - annotations (pod's annotation)
+- controller
+  - annotations (statefulset's annotation)
 - spec:
   - env
   - resources

diff --git a/docs/examples/postgres/clustering/hot-postgres.yaml b/docs/examples/postgres/clustering/hot-postgres.yaml
@@ -6,7 +6,7 @@ metadata:
 spec:
   version: "9.6-v1"
   replicas: 3
-  standbyMode: hot
+  standbyMode: Hot
   storageType: Durable
   storage:
     storageClassName: "standard"

diff --git a/docs/examples/postgres/custom-version/postgresversion.yaml b/docs/examples/postgres/custom-version/postgresversion.yaml
@@ -1,4 +1,4 @@
-apiVersion: kubedb.com/v1alpha1
+apiVersion: catalog.kubedb.com/v1alpha1
 kind: PostgresVersion
 metadata:
   name: timescale-0.9.1

diff --git a/docs/examples/postgres/pg-overview.yaml b/docs/examples/postgres/pg-overview.yaml
@@ -6,7 +6,7 @@ metadata:
 spec:
   version: "9.6-v1"
   replicas: 2
-  standbyMode: hot
+  standbyMode: Hot
   streamingMode: asynchronous
   archiver:
     storage:

diff --git a/docs/examples/postgres/private-registry/pvt-postgresversion.yaml b/docs/examples/postgres/private-registry/pvt-postgresversion.yaml
@@ -1,5 +1,4 @@
-
-apiVersion: kubedb.com/v1alpha1
+apiVersion: catalog.kubedb.com/v1alpha1
 kind: PostgresVersion
 metadata:
   name: "pvt-9.6"

diff --git a/docs/guides/postgres/clustering/ha_cluster.md b/docs/guides/postgres/clustering/ha_cluster.md
@@ -35,7 +35,7 @@ metadata:
 spec:
   version: "9.6-v1"
   replicas: 3
-  standbyMode: warm
+  standbyMode: Warm
   storageType: Ephemeral
 ```
 
@@ -59,7 +59,7 @@ metadata:
 spec:
   version: "9.6-v1"
   replicas: 3
-  standbyMode: hot
+  standbyMode: Hot
   storageType: Ephemeral
 ```
 

diff --git a/docs/guides/postgres/clustering/streaming_replication.md b/docs/guides/postgres/clustering/streaming_replication.md
@@ -237,7 +237,7 @@ metadata:
 spec:
   version: "9.6-v1"
   replicas: 3
-  standbyMode: hot
+  standbyMode: Hot
   storageType: Durable
   storage:
     storageClassName: "standard"

diff --git a/docs/guides/postgres/custom-versions/setup.md b/docs/guides/postgres/custom-versions/setup.md
@@ -57,7 +57,7 @@ RUN sed -r -i "s/[#]*\s*(shared_preload_libraries)\s*=\s*'(.*)'/\1 = 'timescaled
 From there, we would define a PostgresVersion that contains this new image. Lets say we tagged it as `myco/postgres:timescale-0.9.1`
 
 ```yaml
-apiVersion: kubedb.com/v1alpha1
+apiVersion: catalog.kubedb.com/v1alpha1
 kind: PostgresVersion
 metadata:
   name: timescale-0.9.1

diff --git a/docs/guides/postgres/monitoring/using-builtin-prometheus.md b/docs/guides/postgres/monitoring/using-builtin-prometheus.md
@@ -141,7 +141,7 @@ prometheus.io/port=56790
 prometheus.io/scrape=true
 ```
 
-The prometheus server will discover the service endpoint using these specifications and will scrap metrics from exporter.
+The prometheus server will discover the service endpoint using these specifications and will scrape metrics from exporter.
 
 ## Deploy and configure Prometheus Server
 
@@ -255,7 +255,7 @@ deployment.apps/prometheus-server created
 service/prometheus-service created
 ```
 
-Wait for running Deployment’s Pods.
+Wait until pods of the Deployment is running.
 
 ```console
 $ kubectl get pods -n demo --selector=app=prometheus-server

diff --git a/docs/guides/postgres/private-registry/using-private-registry.md b/docs/guides/postgres/private-registry/using-private-registry.md
@@ -13,7 +13,7 @@ section_menu_id: guides
 
 # Using private Docker registry
 
-KubeDB supports using private Docker registry. This tutorial will show you how to use KubeDB to run PostgreSQL database using private Docker images.
+KubeDB supports using private Docker registry. This tutorial will show you how to run KubeDB managed PostgreSQL database using private Docker images.
 
 ## Before You Begin
 
@@ -85,7 +85,7 @@ KubeDB uses images specified in PostgresVersion crd for database, backup and exp
 Here, is an example of PostgresVersion crd. Replace `<YOUR_PRIVATE_REGISTRY>` with your private registy.
 
 ```yaml
-apiVersion: kubedb.com/v1alpha1
+apiVersion: catalog.kubedb.com/v1alpha1
 kind: PostgresVersion
 metadata:
   name: "pvt-9.6"
@@ -138,7 +138,7 @@ spec:
 Now run the command to create this Postgres object:
 
 ```console
-$ kubectl create -f https://raw.githubusercontent.com/kubedb/cli/0.9.0-beta.0/docs/examples/postgres/private-registry/pvt-reg-postgres.yaml 
+$ kubectl create -f https://raw.githubusercontent.com/kubedb/cli/0.9.0-beta.0/docs/examples/postgres/private-registry/pvt-reg-postgres.yaml
 postgres.kubedb.com/pvt-reg-postgres created
 ```
 

diff --git a/docs/guides/postgres/quickstart/quickstart.md b/docs/guides/postgres/quickstart/quickstart.md
@@ -38,7 +38,7 @@ demo    Active  5s
 
 > Note: Yaml files used in this tutorial are stored in [docs/examples/postgres](https://github.com/kubedb/cli/tree/master/docs/examples/postgres) folder in github repository [kubedb/cli](https://github.com/kubedb/cli).
 
->We have designed this tutorial to demonstrate the behaviours that are expected in production environment. If you are just testing some basic functionalities and want to avoid additional hassles due to some safety features of KubeDB, you can follow some tips from [here](/docs/guides/postgres/quickstart/quickstart.md#tips-for-testing).
+>We have designed this tutorial to demonstrate a production setup of KubeDB managed PostgreSQL. If you just want to try out KubeDB, you can bypass some of the safety features following the tips [here](/docs/guides/postgres/quickstart/quickstart.md#tips-for-testing).
 
 ## Install pgAdmin