From ac79faae5869765c5d75fc8573d4f69ed8d24538 Mon Sep 17 00:00:00 2001
From: Felix Kunde <felix.kunde@zalando.de>
Date: Wed, 5 Aug 2020 10:25:07 +0200
Subject: [PATCH] update docs and CRD validation

---
 .../crds/operatorconfigurations.yaml          |  8 ++--
 docs/user.md                                  | 44 +++++++++++++------
 manifests/operatorconfiguration.crd.yaml      |  8 ++--
 pkg/apis/acid.zalan.do/v1/crds.go             |  8 ++--
 4 files changed, 44 insertions(+), 24 deletions(-)

diff --git a/charts/postgres-operator/crds/operatorconfigurations.yaml b/charts/postgres-operator/crds/operatorconfigurations.yaml
index 9efb82d9f..3218decd7 100644
--- a/charts/postgres-operator/crds/operatorconfigurations.yaml
+++ b/charts/postgres-operator/crds/operatorconfigurations.yaml
@@ -138,14 +138,16 @@ spec:
                     type: object
                     required:
                       - secretname
+                      - userkey
+                      - passwordkey
                     properties:
                       secretname:
                         type: string
-                      name:
+                      userkey:
                         type: string
-                      password:
+                      passwordkey:
                         type: string
-                      role:
+                      rolekey:
                         type: string
                       details:
                         type: string
diff --git a/docs/user.md b/docs/user.md
index 54af617a9..29e9594c3 100644
--- a/docs/user.md
+++ b/docs/user.md
@@ -173,23 +173,39 @@ The block above describes the infrastructure role 'dbuser' with password
 automatically be a login role.
 
 With the new option the user can configure the names of secret keys that
-contain the user name, password etc. If the secret uses a template for
-multiple roles as described above, the `template` flag must be set to `true`.
-The secret itself is referenced by the `secretname` key. Please, refer to the
-example manifests to understand who `infrastructure_roles_secrets` has to be
-configured for the [configmap](../manifests/configmap.yaml) (can only
-reference one existing secret) or [CRD configuration](../manifests/postgresql-operator-default-configuration.yaml)
-(reference multiple secret definitions in an array).
+contain the user name, password etc. The secret itself is referenced by the
+`secretname` key. If the secret uses a template for multiple roles as described
+above, list them as separately.
+
+```yaml
+apiVersion: v1
+kind: OperatorConfiguration
+metadata:
+  name: postgresql-operator-configuration
+configuration:
+  kubernetes:
+    infrastructure_roles_secrets:
+    - secretname: "postgresql-infrastructure-roles"
+      userkey: "user1"
+      passwordkey: "password1"
+      rolekey: "inrole1"
+    - secretname: "postgresql-infrastructure-roles"
+      userkey: "user2"
+      ...
+```
+
+Note, only the CRD-based configuration allows for referencing multiple secrets.
+As of now, the ConfigMap is restricted to either one or the existing template
+option with `infrastructure_roles_secret_name`. Please, refer to the example
+manifests to understand how `infrastructure_roles_secrets` has to be configured
+for the [configmap](../manifests/configmap.yaml) or [CRD configuration](../manifests/postgresql-operator-default-configuration.yaml).
 
 If both `infrastructure_roles_secret_name` and `infrastructure_roles_secrets`
 are defined the operator will create roles for both of them. So make sure,
-they do not collide. To migrate to the new format use the same names for the
-secret keys as in the example above and unset the
-`infrastructure_roles_secret_name`.
-
-Note, that with definitions that solely use the infrastructure roles secret
-there is no way to specify role options (like superuser or nologin) or role
-memberships. This is where the ConfigMap comes into play.
+they do not collide. Note also, that with definitions that solely use the
+infrastructure roles secret there is no way to specify role options (like
+superuser or nologin) or role memberships. This is where the additional
+ConfigMap comes into play.
 
 #### Secret plus ConfigMap
 
diff --git a/manifests/operatorconfiguration.crd.yaml b/manifests/operatorconfiguration.crd.yaml
index 1ad796e0e..55b7653ef 100644
--- a/manifests/operatorconfiguration.crd.yaml
+++ b/manifests/operatorconfiguration.crd.yaml
@@ -134,14 +134,16 @@ spec:
                     type: object
                     required:
                       - secretname
+                      - userkey
+                      - passwordkey
                     properties:
                       secretname:
                         type: string
-                      name:
+                      userkey:
                         type: string
-                      password:
+                      passwordkey:
                         type: string
-                      role:
+                      rolekey:
                         type: string
                       details:
                         type: string
diff --git a/pkg/apis/acid.zalan.do/v1/crds.go b/pkg/apis/acid.zalan.do/v1/crds.go
index a3e235e31..c22ed25c0 100644
--- a/pkg/apis/acid.zalan.do/v1/crds.go
+++ b/pkg/apis/acid.zalan.do/v1/crds.go
@@ -916,18 +916,18 @@ var OperatorConfigCRDResourceValidation = apiextv1beta1.CustomResourceValidation
 								Items: &apiextv1beta1.JSONSchemaPropsOrArray{
 									Schema: &apiextv1beta1.JSONSchemaProps{
 										Type:     "object",
-										Required: []string{"secretname"},
+										Required: []string{"secretname", "userkey", "passwordkey"},
 										Properties: map[string]apiextv1beta1.JSONSchemaProps{
 											"secretname": {
 												Type: "string",
 											},
-											"name": {
+											"userkey": {
 												Type: "string",
 											},
-											"password": {
+											"passwordkey": {
 												Type: "string",
 											},
-											"role": {
+											"rolekey": {
 												Type: "string",
 											},
 											"details": {