Skip to content

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

Draft
marceloneppel wants to merge 1 commit into
skl-01-adopt-update-configfrom
skl-02-adopt-database-provider
Draft

[DPE-10844] refactor(relations): adopt the single-kernel client relation#1900
marceloneppel wants to merge 1 commit into
skl-01-adopt-update-configfrom
skl-02-adopt-database-provider

Conversation

@marceloneppel

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. Keeping both means two implementations of one databag contract drifting apart — which is where the doubled-port read-only URI the library fixes came from.

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 it builds: oversee_users() now takes the PostgreSQL client, update_endpoints() takes an optional relation id rather than an event.

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.

Behaviour is unchanged on this substrate. The library keeps VM's relation-<id> role names, its Patroni-member endpoint derivation, its createdb extra-user-role allowance, and its PostgreSQLBaseError catch, all substrate-gated.

Depends on canonical/postgresql-single-kernel-library#209 through #214; pinned to that stack's tip until it is released.

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
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>
@marceloneppel
marceloneppel force-pushed the skl-02-adopt-database-provider branch from b7e5521 to 2ee2329 Compare August 18, 2026 21:34
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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant