Initial global images config

[Kajot-dev]

CHANGE DESCRIPTION

Images that should be used are dependent on version of the operator and crVersion, but the person deploying the postgresql instance migh to not have access to the operator deployment itselft. This also introduces maintenance burden, because teams need to synchronize with the team that manages the operator.

This MR introduces default image per crVersion, so operator can automatically pick certified image related to the crVersion of the postgres instance. Images are embedded at build time, but can be overriden via mounted YAML or configmap by the operator administrators (for example, if they download/mirror from a different registry.

DISCLOSURE: This was AI assisted (of course I have reviewed the AI output and take the responsibility for the code ;) )

NOTE: This is early draft, to discuss if this concept does make sense. There are still multiple things that need to be addressed:

• mounted YAML/configmap is redundant
• extensions.image is not accounted for
• init container image should be possible to override
• need to handle postgis properly. Opeator does not set the postGisVersion on the upstream resource and it is NOT on the bultin list. Any ideas?

If this concept makes sense (please leave feedback!), I'll make a PR do percona docs and the helm chart

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?
• 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?

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds an operator-wide, YAML-driven image configuration system that can be overridden at runtime (file/ConfigMap) and used as the primary source for component image resolution.

Changes:

• Introduces image config types, embedded defaults (YAML), a loader, and deep-merge logic for user overrides.
• Initializes a global image config at operator startup and updates image selection helpers to consult it before env vars.
• Adds unit tests for image lookup and config merging.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
percona/config/images/types.go	Defines config types and image resolution helpers + global config accessor.
percona/config/images/merge.go	Implements deep-merge logic for embedded vs user image configuration.
percona/config/images/loader.go	Loads user config from file/ConfigMap and merges into embedded defaults.
percona/config/images/config.go	Embeds and parses default-images.yaml into DefaultConfig.
percona/config/images/default-images.yaml	Provides embedded default image registry/repositories/tags per CR version.
percona/config/images/types_test.go	Adds tests for image resolution and global config accessors.
percona/config/images/merge_test.go	Adds tests for deep-merge behavior of registries, versions, and tag maps.
internal/config/config.go	Uses operator-wide image config as the first lookup source for component images.
cmd/postgres-operator/main.go	Initializes global image config at startup (with fallback to embedded defaults).

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 7 comments.

[JNKPercona]

Test Name	Result	Time
backup-enable-disable	passed	00:15:05
builtin-extensions	passed	00:06:08
cert-manager-tls	failure	00:08:52
custom-envs	passed	00:20:24
custom-tls	passed	00:08:45
database-init-sql	passed	00:02:24
demand-backup	passed	00:23:06
demand-backup-offline-snapshot	passed	00:13:44
dynamic-configuration	passed	00:05:00
finalizers	passed	00:04:11
init-deploy	failure	00:03:46
huge-pages	passed	00:03:03
major-upgrade-14-to-15	passed	00:11:32
major-upgrade-15-to-16	passed	00:11:30
major-upgrade-16-to-17	passed	00:11:14
major-upgrade-17-to-18	passed	00:09:37
ldap	passed	00:03:50
ldap-tls	passed	00:05:42
monitoring	passed	00:07:37
monitoring-pmm3	passed	00:09:56
one-pod	passed	00:06:09
operator-self-healing	passed	00:11:06
pitr	passed	00:12:05
scaling	passed	00:05:38
scheduled-backup	passed	00:34:12
self-healing	passed	00:09:09
sidecars	passed	00:04:21
standby-pgbackrest	passed	00:18:10
standby-streaming	passed	00:14:41
start-from-backup	passed	00:13:43
tablespaces	passed	00:07:11
telemetry-transfer	passed	00:04:17
upgrade-consistency	passed	00:06:38
upgrade-minor	passed	00:07:07
users	passed	00:05:09

Summary	Value
Tests Run	35/35
Job Duration	01:53:08
Total Test Time	05:45:16

commit: 86382a2
image: perconalab/percona-postgresql-operator:PR-1640-86382a2e5

[egegunes]

@Kajot-dev I didn't get notification for this since it's a draft. Do you want us to review it?

[Kajot-dev]

@Kajot-dev I didn't get notification for this since it's a draft. Do you want us to review it?

@egegunes It would be great, for you to let me know if the concept makes sense and/or would you even be willing to merge something like it as this is a new feature. Code-wise this is not finished, can probably be simpler and I need to address some things and test it - when I do, I'll definitely mark this as ready - I did not want to waste your time with code that is not ready ;)

[egegunes]

@Kajot-dev I'm not sure of the current approach where we need to maintain this new yaml file. I think we first need to discuss the problem in more detail. Would you create an issue describing the problem you want to solve?