fixes spelling errors

Author: wilybrace

docs/content/Security/configure-postgres-operator-rbac.md

@@ -43,7 +43,7 @@ If the user tries to access a namespace that they are not configured for within
     Error: user [pgouser1] is not allowed access to namespace [pgouser2]
 
 
-If you wish to add all avaiable permissions to a *pgorole*, you can specify it by using a single `*` in your configuration. Note that if you are editing your YAML file directly, you will need to ensure to write it as `"*"` to ensure it is recognized as a string.
+If you wish to add all available permissions to a *pgorole*, you can specify it by using a single `*` in your configuration. Note that if you are editing your YAML file directly, you will need to ensure to write it as `"*"` to ensure it is recognized as a string.
 
 The following list shows the current complete list of possible pgo permissions that you can specify within the *pgorole* file when creating roles:
 

docs/content/advanced/custom-configuration.md

@@ -48,7 +48,7 @@ The *postgres-ha.yaml* file is the main configuration file that allows for the
 configuration of a wide variety of tuning parameters for you PostgreSQL cluster.
 This includes various PostgreSQL settings, e.g. those that should be applied to
 files such as `postgresql.conf`, `pg_hba.conf` and `pg_ident.conf`, as well as
-tuning paramters for the High Availability features inlcuded in each cluster.
+tuning parameters for the High Availability features included in each cluster.
 The various configuration settings available can be
 [found here](https://access.crunchydata.com/documentation/patroni/latest/settings/index.html#settings)
 
@@ -218,9 +218,9 @@ postgresql:
     max_wal_senders: 10
 ```
 
-The various key/value pairs provided within the `paramters` section result in the
+The various key/value pairs provided within the `parameters` section result in the
 configuration of the same settings within the `postgresql.conf` file.  Please note that
-settings applied locally to a database server take precendence over those set via the DCS (with the
+settings applied locally to a database server take precedence over those set via the DCS (with the
 exception being those that must be set via the DCS, as
 [described here](https://access.crunchydata.com/documentation/patroni/latest/dynamic_configuration/)).
 

docs/content/advanced/multi-zone-design-considerations.md

@@ -18,7 +18,7 @@ be provisioned in a topology-aware manner according to the specific scheduling r
 This means that when a new PostgreSQL cluster is created, it is necessary to ensure that the volume containing the database
 files for the primary PostgreSQL database within the PostgreSQL clluster is provisioned in the same zone as the node containing the PostgreSQL primary pod that will be accesing the applicable volume.
 
-#### Dynamic Provisioning of Volumes: Default Behavoir
+#### Dynamic Provisioning of Volumes: Default Behavior
 
 By default, the Kubernetes scheduler will ensure any pods created that claim a specific volume via a PVC are scheduled on a 
 node in the same zone as that volume.  This is part of the default Kubernetes [multi-zone support](https://kubernetes.io/docs/setup/multiple-zones/). 
@@ -34,7 +34,7 @@ soon as they are requested, which means volumes are provisioned without knowledg
 This behavior defined using the `volumeBindingMode` configuration applicable to the Storage Class being utilized to
 dynamically provision the volume.  By default,`volumeBindingMode` is set to `Immediate`.  
 
-This default behavoir for dynamic provisioning can be seen in the Storage Class definition for a Google Cloud Engine Persistent Disk (GCE PD):
+This default behavior for dynamic provisioning can be seen in the Storage Class definition for a Google Cloud Engine Persistent Disk (GCE PD):
 
 ```bash
 kind: StorageClass
@@ -50,7 +50,7 @@ As indicated, `volumeBindingMode` indicates the default value of `Immediate`.
 
 #### Issues with Dynamic Provisioning of Volumes in PostgreSQL Operator
 
-Unfortunately, the default setting for dynamic provisinoing of volumes in mulit-zone Kubernetes cluster environments results in undesired behavoir when using the PostgreSQL Operator.  
+Unfortunately, the default setting for dynamic provisinoing of volumes in mulit-zone Kubernetes cluster environments results in undesired behavior when using the PostgreSQL Operator.  
 
 Within the PostgreSQL Operator, a **node label** is implemented as a `preferredDuringSchedulingIgnoredDuringExecution` node
 affinity rule, which is an affinity rule that Kubernetes will attempt to adhere to when scheduling any pods for the cluster,

docs/content/architecture/high-availability/_index.md

@@ -154,7 +154,7 @@ to any Kubernetes jobs created by the PostgreSQL Operator). This includes:
 
 - The primary PG deployment
 - The deployments for each PG replica
-- The `pgBackrest` dedicated repostiory deployment
+- The `pgBackrest` dedicated repository deployment
 - The `pgBouncer` deployment (if enabled for the cluster)
 
 There are three types of Pod Anti-Affinity rules that the Crunchy PostgreSQL

docs/content/installation/other/ansible/prerequisites.md

@@ -65,7 +65,7 @@ directory in the  [postgres-operator project](https://github.com/CrunchyData/pos
 
 Available to Crunchy customers is an RPM containing all the necessary Ansible roles
 and files required for installation using Ansible.  The RPM can be found in Crunchy's
-yum repository.  For information on setting up `yum` to use the Crunchy repoistory,
+yum repository.  For information on setting up `yum` to use the Crunchy repository,
 see the [Crunchy Access Portal](https://access.crunchydata.com/).
 
 To install the Crunchy PostgreSQL Operator Ansible roles using `yum`, run the following
@@ -174,7 +174,7 @@ sets of variables cannot be used at the same time.
 | `db_port`                         | 5432        | **Required** | Set to configure the default port used on all newly created clusters.                                                                                                            |
 | `db_replicas`                     | 1           | **Required** | Set to configure the amount of replicas provisioned on all newly created clusters.                                                                                               |
 | `db_user`                         | testuser    | **Required** | Set to configure the username of the dedicated user account on all newly created clusters.                                                                                       |
-| `disable_failover`                | false       | **Required** | Set to true disable auto failover capabilities on all newly created cluster requests. This cannot be overriden by the client on a cluster create, but on a cluster update. Setting this is not generally recommend, as it disable high-availability capabilities.|
+| `disable_failover`                | false       | **Required** | Set to true disable auto failover capabilities on all newly created cluster requests. This cannot be overridden by the client on a cluster create, but on a cluster update. Setting this is not generally recommend, as it disable high-availability capabilities.|
 | `exporterport`                    | 9187        | **Required** | Set to configure the default port used to connect to postgres exporter.  |
 | `grafana_admin_password`          |             |          | Set to configure the login password for the Grafana administrator. |
 | `grafana_admin_username`          | admin       |          | Set to configure the login username for the Grafana administrator. |

docs/content/installation/other/bash.md

@@ -265,7 +265,7 @@ Prior to using *pgo*, users testing the Operator on a single host can specify th
     pgo version
 ```
 
-That URL address needs to be reachable from your local *pgo* client host.  Your Kubernetes administrator will likely need to create a network route, ingress, or LoadBalancer service to expose the Operator REST API to applications outside of the Kubernetes cluster.  Your Kubernetes administrator might also allow you to run the Kubernetes port-forward command, contact your adminstrator for details.
+That URL address needs to be reachable from your local *pgo* client host.  Your Kubernetes administrator will likely need to create a network route, ingress, or LoadBalancer service to expose the Operator REST API to applications outside of the Kubernetes cluster.  Your Kubernetes administrator might also allow you to run the Kubernetes port-forward command, contact your administrator for details.
 
 Next, the *pgo* client needs to reference the keys used to secure the Operator REST API:
 

docs/content/installation/prerequisites.md

@@ -57,7 +57,7 @@ stream to connect to `nsqd` and `nsqdadmin`:
 | nsqadmin | 4151 |
 | nsqd | 4150 |
 
-If you are using these services, ensure your cluster adminsitrator has given you
+If you are using these services, ensure your cluster administrator has given you
 access to these ports.
 
 ### Application Ports

internal/pgadmin/backoff.go

@@ -39,7 +39,7 @@ const (
 	JitterSmall
 )
 
-// Apply provides a new tiem with respect to t based on the jitter mode
+// Apply provides a new time with respect to t based on the jitter mode
 func (jm Jitter) Apply(t time.Duration) time.Duration {
 	switch jm {
 	case JitterNone: // being explicit in case default case changes

pgo/cmd/pgadmin.go

@@ -105,7 +105,7 @@ func deletePgAdmin(args []string, ns string) {
 
 }
 
-// makeShowPgAdminInterface returns an interface slice of the avaialble values
+// makeShowPgAdminInterface returns an interface slice of the available values
 // in show pgadmin
 func makeShowPgAdminInterface(values []msgs.ShowPgAdminDetail) []interface{} {
 	// iterate through the list of values to make the interface