make run.sh executable from within e2e (#619)

docs/administrator.md

@@ -98,7 +98,7 @@ on `configmaps` resources). This is also done intentionally to avoid breaking
 things if someone decides to configure the same service account in the
 operator's ConfigMap to run Postgres clusters.
 
-### Give K8S users access to create/list `postgresqls`
+### Give K8s users access to create/list `postgresqls`
 
 By default `postgresql` custom resources can only be listed and changed by
 cluster admins. To allow read and/or write access to other human users apply
@@ -363,7 +363,7 @@ used internally in K8s.
 
 ## Logical backups
 
-The operator can manage k8s cron jobs to run logical backups of Postgres
+The operator can manage K8s cron jobs to run logical backups of Postgres
 clusters. The cron job periodically spawns a batch job that runs a single pod.
 The backup script within this pod's container can connect to a DB for a logical
 backup. The operator updates cron jobs during Sync if the job schedule changes;

docs/developer.md

@@ -96,7 +96,7 @@ kubectl get pod -l name=postgres-operator
 The operator employs K8s-provided code generation to obtain deep copy methods
 and K8s-like APIs for its custom resource definitions, namely the
 Postgres CRD and the operator CRD. The usage of the code generation follows
-conventions from the k8s community. Relevant scripts live in the `hack`
+conventions from the K8s community. Relevant scripts live in the `hack`
 directory:
 * `update-codegen.sh` triggers code generation for the APIs defined in `pkg/apis/acid.zalan.do/`,
 * `verify-codegen.sh` checks if the generated code is up-to-date (to be used within CI).
@@ -247,23 +247,20 @@ kubectl logs acid-minimal-cluster-0
 
 ## End-to-end tests
 
-The operator provides reference e2e (end-to-end) tests to ensure various infra
-parts work smoothly together. Each e2e execution tests a Postgres Operator image
-built from the current git branch. The test runner starts a [kind](https://kind.sigs.k8s.io/)
-(local k8s) cluster and Docker container with tests. The k8s API client from
-within the container connects to the `kind` cluster using the standard Docker
-`bridge` network. The tests utilize examples from `/manifests` (ConfigMap is
-used for the operator configuration) to avoid maintaining yet another set of
-configuration files. The kind cluster is deleted if tests complete successfully.
+The operator provides reference end-to-end tests (e2e) (as Docker image) to
+ensure various infrastructure parts work smoothly together. Each e2e execution
+tests a Postgres Operator image built from the current git branch. The test
+runner creates a new local K8s cluster using [kind](https://kind.sigs.k8s.io/),
+utilizes provided manifest examples, and runs e2e tests contained in the `tests`
+folder. The K8s API client in the container connects to the `kind` cluster via
+the standard Docker `bridge` network. The kind cluster is deleted if tests
+finish successfully or on each new run in case it still exists.
 
-End-to-end tests are executed automatically during builds:
+End-to-end tests are executed automatically during builds (for more details,
+see the [README](../e2e/README.md) in the `e2e` folder):
 
 ```bash
-# invoke them from the project's top directory
-make e2e-run
-
-# install kind and build test image before first run
-make e2e-tools e2e-build
+make e2e
 ```
 
 End-to-end tests are written in Python and use `flake8` for code quality.

docs/diagrams/pod.tex

@@ -38,7 +38,7 @@
       node[k8s-label] (app-label) {App}
       node[k8s-label, right=.25cm of app-label] (role-label) {Role}
       node[k8s-label, right=.25cm of role-label] (custom-label) {Custom}
-      node[label, below of=role-label] (k8s-label-label) {K8S Labels}
+      node[label, below of=role-label] (k8s-label-label) {K8s Labels}
       node[border, behind path,
            fit=(app-label)(role-label)(custom-label)(k8s-label-label)
       ] (k8s-labels) {};  \& \&

docs/index.md

@@ -46,7 +46,7 @@ used to complement it.
 Here is a diagram, that summarizes what would be created by the operator, when a
 new Postgres cluster CRD is submitted:
 
-![postgresql-operator](diagrams/operator.png "K8S resources, created by operator")
+![postgresql-operator](diagrams/operator.png "K8s resources, created by operator")
 
 This picture is not complete without an overview of what is inside a single
 cluster pod, so let's zoom in:

docs/reference/cluster_manifest.md

@@ -135,7 +135,7 @@ These parameters are grouped directly under  the `spec` key in the manifest.
   to S3. Default: false. Optional.
 
 * **logicalBackupSchedule**
-  Schedule for the logical backup k8s cron job. Please take
+  Schedule for the logical backup K8s cron job. Please take
   [the reference schedule format](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule)
   into account. Optional. Default is: "30 00 \* \* \*"
 

docs/reference/operator_parameters.md

@@ -158,8 +158,8 @@ configuration they are grouped under the `kubernetes` key.
 
 * **pod_service_account_role_binding_definition**
   This definition must bind pod service account to a role with permission
-  sufficient for the pods to start and for Patroni to access k8s endpoints;
-  service account on its own lacks any such rights starting with k8s v1.8. If
+  sufficient for the pods to start and for Patroni to access K8s endpoints;
+  service account on its own lacks any such rights starting with K8s v1.8. If
   not explicitly defined by the user, a simple definition that binds the
   account to the operator's own 'zalando-postgres-operator' cluster role will
   be used. The default is empty.
@@ -416,7 +416,7 @@ yet officially supported.
 
 ## Logical backup
 
-These parameters configure a k8s cron job managed by the operator to produce
+These parameters configure a K8s cron job managed by the operator to produce
 Postgres logical backups. In the CRD-based configuration those parameters are
 grouped under the `logical_backup` key.