Skip to content

refactor(backups): use the backup module from the single kernel library - #1939

Draft
marceloneppel wants to merge 4 commits into
16/edgefrom
backups-adopt-lib
Draft

refactor(backups): use the backup module from the single kernel library#1939
marceloneppel wants to merge 4 commits into
16/edgefrom
backups-adopt-lib

Conversation

@marceloneppel

@marceloneppel marceloneppel commented Sep 4, 2026

Copy link
Copy Markdown
Member

Issue

Adopts the backups module migration into the single kernel library (postgresql-single-kernel-library #238-#256). The charm drops its own backup module in favour of the library's substrate-neutral backup manager, restore manager, and events handler, ported from the VM and K8s implementations.

Solution

PostgreSQLBackups becomes the library's BackupManager (stanza lifecycle, create/list backups, S3 initialization flow) with RestoreManager beside it and a thin BackupEventsHandler owning the s3-parameters requirer observers and the create-backup/list-backups/restore actions; the charm stays the composition root and injects its bridges (the update_config wrapper, the standby-cluster predicate, the workload as resource provider). The charm-side PostgreSQLS3Client subclass re-derives the TLS CA chain per request so non-TLS S3 keeps verify=None — the static lib client cannot express the dynamic path. The PITR helpers, the patroni restart-condition override/restore pair, and the failed-backup bookkeeping are lib-owned now; the deleted charm helpers' callers rewire to the managers. The rotate-logs lifecycle moves into the library too: the RotateLogs object and both script copies are deleted, the two call sites call the manager, and the PID gets a typed unit-databag accessor. The library is pinned to the integration commit containing the whole migrated module: 14670c3a1c97e705e53a3c5f2b9dd8af4129d89e (draft pin; flips to the released PyPI version before review). Net deletion: src/backups.py and its 2140-line unit suite, with the lib carrying its own tests in the same series.

Known deviations accepted in the lib's events layer: the credentials-changed handler no longer re-runs the primary status refresh and drops the standby-cluster credentials notice, and credentials-gone no longer refreshes a blocked status immediately — the status recovers on the next collect/update-status pass; the charm keeps its own block-message reads for the status message paths.

Checklist

  • I have added or updated any relevant documentation.
  • I have cleaned any remaining cloud resources from my accounts.

Delete the charm-side backup module and rewire the charm onto the
library's BackupManager, RestoreManager and BackupEventsHandler: the
handler owns the s3-credentials, leader-elected and backup action
observers the old module registered; the peer-relation-changed S3
re-initialization path calls BackupManager.initialise_s3_repository;
the restore-completion glue uses the restore manager's PITR helpers and
RestoreManager.restore_patroni_restart_condition.

The lib's S3Client takes a static TLS CA-chain path while the charm
verified dynamically per request depending on the s3 relation's
tls-ca-chain option, so the charm keeps that behavior with a thin
subclass that recomputes the verify path from the s3 parameters.

The charm-side override/restore of the Patroni restart condition and
the PITR log helpers move to RestoreManager; the charm copies are dead
and deleted. src/rotate_logs.py and scripts/rotate_logs.py stay: the
RotateLogs wiring is status-coupled charm code on VM.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
test_backups.py covered the deleted charm-side module; the library
carries its own suite. In test_charm.py, point the backup seams at the
lib managers: BackupManager.can_use_s3_repository /
start_stop_pgbackrest_service / coordinate_stanza_fields and
RestoreManager.log_pitr_last_transaction_time, and import
CANNOT_RESTORE_PITR from single_kernel_postgresql.utils.backup. The
test_override_patroni_restart_condition case goes with the deleted
charm-side override/restore helpers it exercised.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Point postgresql-charms-single-kernel at the archive tarball of
dc17cc6f53c6a2b6f437b3e69f8a591b1a6892cd (integration/backups-final on
the library's backups-18-rotate-logs-script branch), keeping the
[postgresql, vm] extras, and relock. Draft-only testing pin: this flips
to the released PyPI version before review.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@github-actions github-actions Bot added the Libraries: Out of sync The charm libs used are out-of-sync label Sep 4, 2026
@marceloneppel
marceloneppel force-pushed the backups-adopt-lib branch 4 times, most recently from 100fac0 to 4b7758a Compare September 4, 2026 15:59
@marceloneppel marceloneppel added the not bug or enhancement PR is not 'bug' or 'enhancement'. For release notes label Sep 4, 2026
The RotateLogs object was status-coupled charm wiring around spawning
the (lib-shipped) script and tracking its PID; the manager owns the
lifecycle now with the same guards through state, so the charm drops
the module and rewires its two call sites. The pin moves to the
integration commit carrying it.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Libraries: Out of sync The charm libs used are out-of-sync not bug or enhancement PR is not 'bug' or 'enhancement'. For release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant