postgres-operator
postgres-operator copied to clipboard
zalando
Dynamic Configuration options to patroni?
Dynamic Configuration options to patroni? Could someone show an example of how to pass dynamic configurations from postgres-operator to patroni?
You can pass these parameters via a postgresql manifest.
Note, that not all features of Patroni are exposed. However, you could still enable it with patronictl when execed into the pods. Some user already work on exposing feature such as standby leader and synchronous replication. What options do you need?
@srflaxu40 I believe https://github.com/zalando/postgres-operator/issues/505 is the issue @FxKu is referring to. There even is code available, just not in the form of a PR. Question is, if users should be able to fiddle with every option Patroni has. What use is an operator if it only copies over configuration snippets from your postgresql manifest to the underlying component?
But then, having the ability to use all available Patroni settings would be great - Maybe in the form of a global map to allow only certain things to be changed per manifest or to set a global default (just like the sidecars work).
I see what you guys mean, but what if I need to initialize a database and some tables or a schema on startup? How would I add this to the underlying patroni/spilo containers that get spun up in an automated fashion?
https://github.com/zalando/spilo/tree/master/postgres-appliance/scripts you can find scripts here that are executed on the promote.
I suggest you look into this. We use the post promote hook to roll out scripts that are common to all databases.
Everything else is then later added by the applications.
Ideally noone needs to fiddle so much with the manifest and the patroni options, this is not the plan or idea of the operator.
Yeah, but how would I use these scripts? How would I call post_init.sh to execute my custom .sh sql script?
You create your own docker image based on our spilo and put the files in the right place and modify the post_init.sh script to your liking.
@Jan-M I appreciate your help and please forgive my ignorance - could you give me an example using spilo image with our custom dockerfile; we are using spilo as the base image.
#ARG POSTGRES_VERSION=11.0
#ARG POSTGIS_VERSION=2.5
#FROM kartoza/postgis:${POSTGRES_VERSION}-${POSTGIS_VERSION}
FROM registry.opensource.zalan.do/acid/spilo-cdp-12:1.6-p16
COPY init.sql /init.sql
I would think that by simply overwriting in a similar manner the init.sh script to the Docker image in the right place.
You can also do something ugly I guess like:
FROM spilo
COPY your_init.sh
RUN echo "\nyour_init.sh" >> /scritps/post_init.sh
@Jan-M It seems like it wants to run some sort of similar script with zalando arg?
2020-01-13 18:03:42,598 INFO: running post_bootstrap
#### POSTGRES CONFIG ####
USER:
PASSWORD:
DATABASE:
Password for user -d:
psql: error: could not connect to server: fe_sendauth: no password supplied
2020-01-13 18:03:47,639 ERROR: post_init script /scripts/post_init.sh "zalandos" returned non-zero code 2
2020-01-13 18:03:47,642 INFO: removing initialize key after failed attempt to bootstrap the cluster
2020-01-13 18:03:47,687 INFO: renaming data directory to /home/postgres/pgdata/pgroot/data_2020-01-13-18-03-47
Particularly psql: error: could not connect to server: fe_sendauth: no password supplied 2020-01-13 18:03:47,639 ERROR: post_init script /scripts/post_init.sh "zalandos"
That seems to break username / password stuff for my custom infrastructure roles too...
Oh, I think I figured out what the issue was it was just matter of concatenating the file properly as you showed me.
Okay one funny behavior i have noticed is that this script seems to run before my infrastructure roles are initialized does this mean I have to create the usernames /passwords outside of that scope for this to run succesfully using anticipated roles defined in the infrastructure roles manifest in the postgres-operator?
We are using helmcharts for deploying the postgres-operator and we would like to add parameter max_timelines_history because when it is in default value (0 in practice infinite) it can cause Kubernetes API errors when having long running and big environment:
{"reason":"FieldValueTooLong","message":"Too long: must have at most 262144 bytes","field":"metadata.annotations"}
Is there a way on how to update this value using helmchart values? We are using official releases and it is hard to cherry pick changes in actual helmchart CRDs or customizing image for each new release. There should be something more straight forward.
We are using helmcharts for deploying the postgres-operator and we would like to add parameter max_timelines_history because when it is in default value (0 in practice infinite) it can cause Kubernetes API errors when having long running and big environment:
{"reason":"FieldValueTooLong","message":"Too long: must have at most 262144 bytes","field":"metadata.annotations"}Is there a way on how to update this value using helmchart values? We are using official releases and it is hard to cherry pick changes in actual helmchart CRDs or customizing image for each new release. There should be something more straight forward.
Hi, any news about adding the possibility to set patroni max_timelines_history through postgresl manifest ?
