postgres-operator/e2e
Jociele Padilha a5663da64f
add the pg version 16 (#2557)
* add the pg version 16

* add comma after pg16 in crds api

* change minimal_major_version to 12

* add new spilo image for pg16

* edit the registry from current and lazy spilo

* Update e2e/run.sh

Co-authored-by: Felix Kunde <felix-kunde@gmx.de>

* Update README.md

Co-authored-by: Felix Kunde <felix-kunde@gmx.de>

* add pg 11 to be compatible for the existing DBs

* update pq, pyyaml,k8s and kind version

* skip test_infrastructure_roles

* skip another test

* remove the skipping

* adjust the verification of new Patroni version states

---------

Co-authored-by: Felix Kunde <felix-kunde@gmx.de>
2024-03-13 16:43:25 +01:00
..
scripts Improve rolling upgrades and rolling upgrade continue (#1341) 2021-02-26 15:38:58 +01:00
tests add the pg version 16 (#2557) 2024-03-13 16:43:25 +01:00
Dockerfile Remove scm-source.json creation (#2301) 2023-04-21 16:45:15 +02:00
Makefile add the pg version 16 (#2557) 2024-03-13 16:43:25 +01:00
README.md Avoid syncing when possible (#1274) 2021-01-14 09:53:09 +01:00
exec.sh Lookup function installation (#1171) 2020-10-19 16:18:58 +02:00
exec_into_env.sh switch to policy API v1 for PDBs (#2008) 2022-10-06 09:43:17 +02:00
kind-cluster-postgres-operator-e2e-tests.yaml Enable specifying PVC retention policy for auto deletion (#2343) 2023-09-08 13:17:37 +02:00
requirements.txt add the pg version 16 (#2557) 2024-03-13 16:43:25 +01:00
run.sh add the pg version 16 (#2557) 2024-03-13 16:43:25 +01:00

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

Notice

The manifest folder in e2e tests folder is not commited to git, it comes from /manifests

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 main

To run both the build and test step you can invoke make e2e from the parent directory.

To run the end 2 end test and keep the kind state execute:

NOCLEANUP=True ./run.sh main

Run individual test

After having executed a normal E2E run with NOCLEANUP=True Kind still continues to run, allowing you subsequent test runs.

To run an individual test, run the following command in the e2e directory

NOCLEANUP=True ./run.sh main tests.test_e2e.EndToEndTestCase.test_lazy_spilo_upgrade

Inspecting Kind

If you want to inspect Kind/Kubernetes cluster, switch kubeconfig file and context

# save the old config in case you have it
export KUBECONFIG_SAVED=$KUBECONFIG

# use the one created by e2e tests
export KUBECONFIG=/tmp/kind-config-postgres-operator-e2e-tests

# this kubeconfig defines a single context
kubectl config use-context kind-postgres-operator-e2e-tests

or use the following script to exec into the K8s setup and then use kubectl

./exec_into_env.sh

# use kubectl
kubectl get pods

# watch relevant objects
./scripts/watch_objects.sh

# get operator logs
./scripts/get_logs.sh

If you want to inspect the state of the kind cluster manually with a single command, add a context flag

kubectl get pods --context kind-kind

or set the context for a few commands at once

Cleaning up Kind

To cleanup kind and start fresh

e2e/run.sh cleanup

That also helps in case you see the

ERROR: no nodes found for cluster "postgres-operator-e2e-tests"

that happens when the kind cluster was deleted manually but its configuraiton file was not.

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