public_git/postgres-operator
1
0
Fork 0
mirror of https://github.com/zalando/postgres-operator.git synced 2026-10-05 11:02:00 +02:00
Code Issues Projects Releases Wiki Activity

reflect feedback

Browse Source
This commit is contained in:
Felix Kunde
2020-08-05 13:31:01 +02:00
parent ac79faae58
commit 79b53d8038
2 changed files with 8 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/operator_parameters.md
+4 -5
View File
@@ -253,14 +253,13 @@ configuration they are grouped under the `kubernetes` key.
* **infrastructure_roles_secret_name**
*deprecated*: namespaced name of the secret containing infrastructure roles
names and passwords.
with user names, passwords and role membership.
* **infrastructure_roles_secrets**
array of infrastructure role definitions which reference existing secrets
and specify the keys for extract credentials from them such as user name,
password and role membership. For the configmap this has to be a string
which allows referencing only one infrastructure roles secret.
The default is empty.
and specify the key names from which user name, password and role membership
are extracted. For the ConfigMap this has to be a string which allows
referencing only one infrastructure roles secret. The default is empty.
* **pod_role_label**
name of the label assigned to the Postgres pods (and services/endpoints) by
docs/user.md
+4 -4
View File
@@ -154,7 +154,7 @@ Infrastructure roles can be specified by the `infrastructure_roles_secrets`
parameter where you can reference multiple existing secrets. Prior to `v1.6.0`
the operator could only reference one secret with the
`infrastructure_roles_secret_name` option. However, this secret could contain
multiple roles using the same set of keys with incremented indexes.
multiple roles using the same set of keys plus incrementing index.
```yaml
apiVersion: v1
@@ -172,10 +172,10 @@ The block above describes the infrastructure role 'dbuser' with password
'secret' that is a member of the 'operator' role. The resulting role will
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. The secret itself is referenced by the
With the new option users can configure the names of secret keys that 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.
above list them separately.
```yaml
apiVersion: v1