7cf2fae6df
Extend infrastructure roles handling
Postgres Operator uses infrastructure roles to provide access to a database for
external users e.g. for monitoring purposes. Such infrastructure roles are
expected to be present in the form of k8s secrets with the following content:
inrole1: some_encrypted_role
password1: some_encrypted_password
user1: some_entrypted_name
inrole2: some_encrypted_role
password2: some_encrypted_password
user2: some_entrypted_name
The format of this content is implied implicitly and not flexible enough. In
case if we do not have possibility to change the format of a secret we want to
use in the Operator, we need to recreate it in this format.
To address this lets make the format of secret content explicitly. The idea is
to introduce a new configuration option for the Operator.
infrastructure_roles_secrets:
- secretname: k8s_secret_name
userkey: some_encrypted_name
passwordkey: some_encrypted_password
rolekey: some_encrypted_role
- secretname: k8s_secret_name
userkey: some_encrypted_name
passwordkey: some_encrypted_password
rolekey: some_encrypted_role
This would allow Operator to use any avalable secrets to prepare infrastructure
roles. To make it backward compatible simulate the old behaviour if the new
option is not present.
The new configuration option is intended be used mainly from CRD, but it's also
available via Operator ConfigMap in a limited fashion. For ConfigMap one can
put there only a string with one secret definition in the following format (as
a string):
infrastructure_roles_secrets: |
secretname: k8s_secret_name,
userkey: some_encrypted_name,
passwordkey: some_encrypted_password,
rolekey: some_encrypted_role
Note than only one secret could be specified this way, no multiple secrets are
allowed.
Eventually the resulting list of infrastructure roles would be a total sum of
all supported ways to describe it, namely legacy via
infrastructure_roles_secret_name and infrastructure_roles_secrets from both
ConfigMap and CRD.
|
||
|---|---|---|
| .. | ||
| tests | ||
| Dockerfile | ||
| Makefile | ||
| README.md | ||
| exec.sh | ||
| kind-cluster-postgres-operator-e2e-tests.yaml | ||
| requirements.txt | ||
| run.sh | ||
README.md
Postgres Operator end-to-end tests
End-to-end tests shall ensure that the Postgres Operator does its job when
applying manifests against a Kubernetes (K8s) environment. A test runner
Dockerfile is provided to run e2e tests without the need to install K8s and
its runtime kubectl in advance. The test runner uses
kind to create a local K8s cluster which runs on
Docker.
Prerequisites
Docker Go
Build test runner
In the directory of the cloned Postgres Operator repository change to the e2e folder and run:
make
This will build the postgres-operator-e2e-tests image and download the kind
runtime.
Run tests
In the e2e folder you can invoke tests either with make test or with:
./run.sh
To run both the build and test step you can invoke make e2e from the parent
directory.
Covered use cases
The current tests are all bundled in test_e2e.py:
- support for multiple namespaces
- scale Postgres cluster up and down
- taint-based eviction of Postgres pods
- invoking logical backup cron job
- uniqueness of master pod
- custom service annotations