Add LoggingConfiguration struct for providing log path to pgbackrest … #4263
Conversation
| // Logging configuration for pgbackrest processes running in postgres instance pods. | ||
| // +optional | ||
| Log *LoggingConfiguration `json:"log,omitempty"` |
There was a problem hiding this comment.
I am open to other ideas for the placement of this LoggingConfiguration.
There was a problem hiding this comment.
I do wonder if there would be an even better place to put it, but not sure where, so: Seems reasonable to me for now.
There was a problem hiding this comment.
Hmm... Theoretically users could have multiple InstanceSets that have different additional volumes mounted, which would mean we'd need to allow different log paths per InstanceSet... So maybe the LoggingConfiguration should go on the PostgresInstanceSetSpec struct? 🤔
There was a problem hiding this comment.
But we mount the same pgbackrest config to every postgres pod, right?
There was a problem hiding this comment.
I was thinking that we had a different pgbackrest_instance.conf file per InstanceSet, but it seems you are correct... Only one pgbackrest_instance.conf regardless of the number of InstanceSets... Do we move the Volumes.Additional out of the PostgresInstanceSetSpec and into the PostgresClusterSpec and mount them into all instances so the log paths can be consistent amongst instances? 🤔
There was a problem hiding this comment.
But then we'd be mounting the same PVC to all the different InstanceSet pods and having them all write to the same locations. (Which actually is the situation now if you have a single instanceSet with multiple replicas, so... it's already a fraught situation.)
Since we currently only allow people to bring their own volumes (rather than set up a template), people have to be a little careful about the pods-volumes connections. The safest scenario would probably be something like
- multiple instance sets
- each with only 1 replica
- each with the same name of additional volumes but different PVC claims
That way, the config remains the same without any worry about collisions/overwriting between processes (where does each pod log? to the PVC that only that pod is connected)
There was a problem hiding this comment.
In other words, I think this is (for now) going to be a lot of socialization and documentation.
pkg/apis/postgres-operator.crunchydata.com/v1/pgbackrest_types.go
Outdated
Show resolved
Hide resolved
acabe60 to
1312df1
Compare
69d7ce8 to
a8dceef
Compare
pkg/apis/postgres-operator.crunchydata.com/v1beta1/shared_types.go
Outdated
Show resolved
Hide resolved
pkg/apis/postgres-operator.crunchydata.com/v1/pgbackrest_types.go
Outdated
Show resolved
Hide resolved
pkg/apis/postgres-operator.crunchydata.com/v1/pgbackrest_types.go
Outdated
Show resolved
Hide resolved
9bb7e57 to
1cbac34
Compare
pkg/apis/postgres-operator.crunchydata.com/v1/postgrescluster_types.go
Outdated
Show resolved
Hide resolved
…processes. Add ability to send pgbackrest logs to additional volume for repo host processes.
Add maxlength to log path and optional tag to volumes.
Add validation tests for log path and additional volumes.
…l volume that matches the log path when attempting to log pgbackrest sidecar to /volumes. Add test cases.
f5261ca to
9c39b1e
Compare
…processes.
Add ability to send pgbackrest logs to additional volume for repo host processes.
Checklist:
Type of Changes:
What is the current behavior (link to any open issues here)?
What is the new behavior (if this is a feature change)?
Other Information: