Skip to content

[DPE-10887] refactor(relations): adopt the single-kernel client relation - #1900

Open
marceloneppel wants to merge 2 commits into
16/edgefrom
skl-02-adopt-database-provider
Open

[DPE-10887] refactor(relations): adopt the single-kernel client relation#1900
marceloneppel wants to merge 2 commits into
16/edgefrom
skl-02-adopt-database-provider

Conversation

@marceloneppel

@marceloneppel marceloneppel commented Aug 17, 2026

Copy link
Copy Markdown
Member

Issue

src/relations/postgresql_provider.py (645 lines) is a near-copy of the K8s charm's version of the same file, and the library now owns the postgresql-client relation.

Solution

Deletes the charm's provider and its tests, and constructs single_kernel_postgresql.events.database.DatabaseEventsHandler instead. The remaining call sites move to the manager: oversee_users() now takes the PostgreSQL client, update_endpoints() takes an optional relation id rather than an event.

The library pin is the published 16.3.6 from PyPI. Following the library review, the charm is the composition root for the client-relation subsystem: it constructs DatabaseProvides and DatabaseManager itself and passes the manager to the events handler. update_endpoints takes its inputs caller-side — the online Patroni members (gathered only on the leader, so non-leader units fire no extra REST calls) and the client TLS files.

Two seams close with it:

  • refresh_endpoints is gone. ConfigManager holds the database manager and refreshes endpoints itself.
  • update_config no longer takes a user hash. _collect_user_relations delegates to the manager, and the hash is derived from the same relation data the user-databases map comes from, so generate_user_hash had nothing left to do.

relations_user_databases_map stays here — its computation diverges between the substrates and belongs to the core event-loop phase.

Checklist

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

@marceloneppel
marceloneppel force-pushed the skl-02-adopt-database-provider branch from 6ddf535 to f18998d Compare August 17, 2026 19:47
@github-actions github-actions Bot added the Libraries: Out of sync The charm libs used are out-of-sync label Aug 18, 2026
@marceloneppel
marceloneppel force-pushed the skl-01-adopt-update-config branch 2 times, most recently from 43dac9e to 429abf3 Compare August 18, 2026 21:20
@marceloneppel
marceloneppel force-pushed the skl-02-adopt-database-provider branch from b7e5521 to 2ee2329 Compare August 18, 2026 21:34
Base automatically changed from skl-01-adopt-update-config to 16/edge August 19, 2026 21:07
@marceloneppel marceloneppel added the not bug or enhancement PR is not 'bug' or 'enhancement'. For release notes label Aug 20, 2026
@marceloneppel marceloneppel changed the title [DPE-10844] refactor(relations): adopt the single-kernel client relation [DPE-10887] refactor(relations): adopt the single-kernel client relation Aug 20, 2026
@marceloneppel
marceloneppel force-pushed the skl-02-adopt-database-provider branch 2 times, most recently from 90720c8 to 065e94d Compare August 20, 2026 20:09
Move the database (client) relation provider into the single-kernel library:
delete the charm's src/relations/postgresql_provider.py and its tests, and
wire the provider events through the lib's DatabaseManager. The charm
implements get_resource_provider so the lib's ConfigManager reads substrate
resources via the resource_provider injection contract (lib #215) on the
db-provider lib branch.

Pin the lib at the rebased test/02-db-events tip (archive-URL SHA, since the
db-provider stack is not yet published to PyPI), stacked on the skl-01 16.3.5
update_config adoption.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
…relation

The client-relation subsystem the branch adopts is now on 16/edge and
published: the pin moves from the pre-release archive-URL stopgap
(706cd21, the validated stack tip) to the released 16.3.6 from PyPI
(extras: postgresql, vm) — the sdist is byte-identical to the validated
tree, so the adoption code is unchanged apart from the wiring that
follows the lib's review rework: the charm is now the composition root
constructing DatabaseProvides and DatabaseManager, and the endpoint
inputs (online Patroni members on VM, client TLS files) are gathered
caller-side and threaded into update_endpoints, as the lib no longer
holds peer-manager references.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel
marceloneppel force-pushed the skl-02-adopt-database-provider branch from b63386f to 61af3a2 Compare August 24, 2026 17:59
@marceloneppel
marceloneppel marked this pull request as ready for review August 24, 2026 19:54
@marceloneppel
marceloneppel requested a review from a team as a code owner August 24, 2026 19:54
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