Allow specifying sidecars and env vars for the repo host

[jsierles]

CHANGE DESCRIPTION

Problem:

The repo host env vars and sidecars were not configurable.

Solution:

This PR simply adds support for env vars and sidecars in the Postgres CRD. Changes to the Helm chart are needed, and will come in a separate PR.

CHECKLIST

Jira

• [ ] Is the Jira ticket created and referenced properly?
• [ ] Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
• [ ] Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

• [ ] Is an E2E test/test case added for the new feature/change?
• [x] Are unit tests added where appropriate?

Config/Logging/Testability

• [ ] Are all needed new/changed options added to default YAML files?
• [ ] Are all needed new/changed options added to the Helm Chart?
• [ ] Did we add proper logging messages for operator actions?
• [ ] Did we ensure compatibility with the previous version or cluster upgrade process?
• [ ] Does the change support oldest and newest supported PG version?
• [ ] Does the change support oldest and newest supported Kubernetes version?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Joshua Sierles seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[JNKPercona]

Test name	Status
custom-extensions	passed
custom-tls	passed
demand-backup	passed
finalizers	passed
init-deploy	passed
monitoring	passed
one-pod	passed
operator-self-healing	passed
pitr	passed
scaling	passed
scheduled-backup	failure
self-healing	passed
sidecars	passed
start-from-backup	passed
tablespaces	passed
telemetry-transfer	passed
upgrade-consistency	passed
upgrade-minor	passed
users	passed
We run 19 out of 19

commit: https://github.com/percona/percona-postgresql-operator/pull/1080/commits/e878215c97c330c00b910cf770ac7c92893dce90 image: perconalab/percona-postgresql-operator:PR-1080-e878215c9

[jsierles]

OK, we will submit! Will there be a safe upgrade path from 2.5.0 to 2.7.0? We're debating now with which version to launch. Right now the challenge seems to be about the CRD updates potentially causing issues (like sidecars being replaced with containers).

[hors]

OK, we will submit! Will there be a safe upgrade path from 2.5.0 to 2.7.0? We're debating now with which version to launch. Right now the challenge seems to be about the CRD updates potentially causing issues (like sidecars being replaced with containers).

PGO v2.6.0 will be available tomorrow, and I suggest using the latest version. All new options take effect only when using the new CR version. For example, you can run Operator 2.6.0 with CR version 2.5.0, and all existing options will continue to work. Once you upgrade the CR version, you can start using the new options.

Regarding updates, we recommend that users follow a sequential upgrade path (e.g., 2.5.0 → 2.6.0 → 2.7.0) rather than skipping versions. Additionally, we aim to deprecate old options gradually rather than replacing them outright.

[jsierles]

"CR version" refers to the deploy/crd.yaml file for each release?

[hors]

"CR version" refers to the deploy/crd.yaml file for each release?

I'm referring to this line. Previously, versioning was handled differently, but now we maintain a single version in CRDs and manage headline versioning within the operator code.

The main goal is to prevent unnecessary restarts when updating the operator. For example, if a new environment variable is introduced in version 2.7.0, without crVersion checking, all clusters managed by the operator would restart as soon as the operator image is updated. However, by handling this in the operator code, the new environment variable is only added when crVersion >= 2.7.0.

This means that updating the operator image alone won’t trigger cluster restarts or introduce new settings unexpectedly. When you're ready for a database update, you can manually bump crVersion and make any additional changes in the CR, triggering a controlled restart where all new options take effect.

This approach also allows us to manage feature availability e.g., Feature A can be enabled only for crVersion >= 2.7.0. As a result, different PostgreSQL cluster versions can coexist under the same operator, making updates more predictable and manageable.

[jsierles]

OK - one question though. Can't only one version of the CRD exist in the k8s cluster? Or will specifying an earlier version simply ignore certain fields? And, does this mean you wouldn't need to run multiple operators, at least for a while? Right now we run cluster wide operators so want to be careful with updates that could affect many clusters.

[hors]

OK - one question though. Can't only one version of the CRD exist in the k8s cluster? Or will specifying an earlier version simply ignore certain fields? And, does this mean you wouldn't need to run multiple operators, at least for a while? Right now we run cluster wide operators so want to be careful with updates that could affect many clusters.

yes, CRD has a cluster scope, but the idea is that the latest version of CRD should work with the previous ver of the PG cluster. E.g., you can have CRD ver 2.7.0, and it should work with CR versions 2.7.0 , 2.6.0, and 2.5.0. We support the last three versions.

[hors]

@jsierles JFYI, we are almost finished with the development cycle for the MySQL operator. For the next two or even three weeks, we will be focusing on PGO. If you want to include more changes in PGO 2.7.0, please try to submit PRs during this period.

@jsierles do you need any help from our end?

[jsierles]

We've added support for this feature using secrets, but haven't submitted a PR. If you're interested in taking it over, feel free, otherwise we'll try to submit one when we can, later this week.

[hors]

We've added support for this feature using secrets, but haven't submitted a PR. If you're interested in taking it over, feel free, otherwise we'll try to submit one when we can, later this week.

Good day, @jsierles, Do you have time to finish this PR? We have about two weeks left to include it in the upcoming PGO release (PGO 2.7.0). Thanks. P.S. we can finish it from our end but only for 2.8.0