Update CRD configuration docs and fix the CDP build (#414)

* Update CRD configuration docs

* document resource consumption of the operator

* Add talks by Oleksii

docs/index.md

@@ -51,7 +51,9 @@ Please, report any issues discovered to https://github.com/zalando-incubator/pos
 
 ## Talks
 
-1. "PostgreSQL High Availability on Kubernetes with Patroni" talk by Oleksii Kliukin, Atmosphere 2018: [video](https://www.youtube.com/watch?v=cFlwQOPPkeg) | [slides](https://speakerdeck.com/alexeyklyukin/postgresql-high-availability-on-kubernetes-with-patroni)
+1. "PostgreSQL and Kubernetes: DBaaS without a vendor-lock" talk by Oleksii Kliukin, PostgreSQL Sessions 2018: [slides](https://speakerdeck.com/alexeyklyukin/postgresql-and-kubernetes-dbaas-without-a-vendor-lock)
+
+2. "PostgreSQL High Availability on Kubernetes with Patroni" talk by Oleksii Kliukin, Atmosphere 2018: [video](https://www.youtube.com/watch?v=cFlwQOPPkeg) | [slides](https://speakerdeck.com/alexeyklyukin/postgresql-high-availability-on-kubernetes-with-patroni)
 
 2. "Blue elephant on-demand: Postgres + Kubernetes" talk by Oleksii Kliukin and Jan Mussler, FOSDEM 2018: [video](https://fosdem.org/2018/schedule/event/blue_elephant_on_demand_postgres_kubernetes/) | [slides (pdf)](https://www.postgresql.eu/events/fosdem2018/sessions/session/1735/slides/59/FOSDEM%202018_%20Blue_Elephant_On_Demand.pdf)
 

docs/reference/operator_parameters.md

@@ -10,29 +10,37 @@ configuration.
   configuration structure. There is an
   [example](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/configmap.yaml)
 
-* CRD-based configuration.  The configuration is stored in the custom YAML
+* CRD-based configuration. The configuration is stored in a custom YAML
-  manifest, an instance of the custom resource definition (CRD) called
+  manifest. The manifest is an instance of the custom resource definition (CRD) called
-  `OperatorConfiguration`.  This CRD is registered by the operator
+  `OperatorConfiguration`. The operator registers this CRD 
-  during the start when `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` variable is
+  during the start and uses it for configuration if the [operator deployment manifest ](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgres-operator.yaml#L21) sets the `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` env variable to a non-empty value. The variable should point to the
-  set to a non-empty value. The CRD-based configuration is a regular YAML
+  `postgresql-operator-configuration` object in the operator's namespace.
-  document; non-scalar keys are simply represented in the usual YAML way. The
+
-  usage of the CRD-based configuration is triggered by setting the
+  The CRD-based configuration is a regular YAML
-  `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` variable, which should point to the
+  document; non-scalar keys are simply represented in the usual YAML way. 
-  `postgresql-operator-configuration` object name in the operators namespace.
   There are no default values built-in in the operator, each parameter that is
   not supplied in the configuration receives an empty value.  In order to
   create your own configuration just copy the [default
   one](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
   and change it.
 
-CRD-based configuration is more natural and powerful then the one based on
+  To test the CRD-based configuration locally, use the following
+  ```bash
+  kubectl create -f manifests/operator-service-account-rbac.yaml
+  kubectl create -f manifests/postgres-operator.yaml # set the env var as mentioned above
+  kubectl create -f manifests/postgresql-operator-default-configuration.yaml
+  kubectl get operatorconfigurations postgresql-operator-default-configuration -o yaml
+  ```
+  Note that the operator first registers the definition of the CRD   `OperatorConfiguration` and then waits for an instance of the CRD to be created. In between these two event the operator pod may be failing since it cannot fetch the not-yet-existing `OperatorConfiguration` instance.
+
+The CRD-based configuration is more powerful than the one based on
 ConfigMaps and should be used unless there is a compatibility requirement to
 use an already existing configuration. Even in that case, it should be rather
 straightforward to convert the configmap based configuration into the CRD-based
 one and restart the operator. The ConfigMaps-based configuration will be
 deprecated and subsequently removed in future releases.
 
-Note that for the CRD-based configuration configuration groups below correspond
+Note that for the CRD-based configuration groups of configuration options below correspond
 to the non-leaf keys in the target YAML (i.e. for the Kubernetes resources the
 key is `kubernetes`). The key is mentioned alongside the group description. The
 ConfigMap-based configuration is flat and does not allow non-leaf keys.
@@ -46,7 +54,6 @@ They will be deprecated and removed in the future.
 Variable names are underscore-separated words.
 
 
-
 ## General
 
 Those are top-level keys, containing both leaf keys and groups.
@@ -222,7 +229,7 @@ CRD-based configuration.
   settings. The default is `1Gi`.
 
 * **set_memory_request_to_limit**
-  Set `memory_request` to `memory_limit` for all Postgres clusters (the default value is also increased). This prevents certain cases of memory overcommitment at the cost of overprovisioning memory and potential scheduling problems for containers with high memory limits due to the lack of memory on Kubernetes cluster nodes. This affects all containers (Postgres, Scalyr sidecar, and other sidecars). The default is `false`.
+  Set `memory_request` to `memory_limit` for all Postgres clusters (the default value is also increased). This prevents certain cases of memory overcommitment at the cost of overprovisioning memory and potential scheduling problems for containers with high memory limits due to the lack of memory on Kubernetes cluster nodes. This affects all containers created by the operator (Postgres, Scalyr sidecar, and other sidecars); to set resources for the operator's own container, change the [operator deployment manually](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgres-operator.yaml#L13). The default is `false`.
 
 * **enable_shm_volume**
   Instruct operator to start any new database pod without limitations on shm

manifests/minimal-postgres-manifest.yaml

@@ -15,7 +15,8 @@ spec:
     - createdb
 
     # role for application foo
-    foo_user:
+    foo_user: []
+
   
   #databases: name->owner
   databases:

manifests/postgres-operator.yaml

@@ -14,6 +14,13 @@ spec:
       - name: postgres-operator
         image: registry.opensource.zalan.do/acid/smoke-tested-postgres-operator:v1.0.0-21-ge39915c
         imagePullPolicy: IfNotPresent
+        resources:
+          requests:
+            cpu: 500m
+            memory: 250Mi
+          limits:
+            cpu: 2000m
+            memory: 500Mi
         env:
         # provided additional ENV vars can overwrite individual config map entries  
         - name: CONFIG_MAP_NAME

pkg/cluster/k8sres.go

@@ -661,6 +661,7 @@ func (c *Cluster) generateStatefulSet(spec *acidv1.PostgresSpec) (*v1beta1.State
 		volumeClaimTemplate *v1.PersistentVolumeClaim
 	)
 
+	// Improve me. Please.
 	if c.OpConfig.SetMemoryRequestToLimit {
 
 		// controller adjusts the default memory request at operator startup