Skip to content

[DPE-11198] feat(watcher): own the relation events and wire the handler (2/3) - #275

Draft
marceloneppel wants to merge 1 commit into
watcher-1-port-handlerfrom
watcher-2-wire-handler
Draft

[DPE-11198] feat(watcher): own the relation events and wire the handler (2/3)#275
marceloneppel wants to merge 1 commit into
watcher-1-port-handlerfrom
watcher-2-wire-handler

Conversation

@marceloneppel

@marceloneppel marceloneppel commented Sep 4, 2026

Copy link
Copy Markdown
Member

Issue

Stacks on #274.

Solution

  • Completes the ported handler with the three relation events — joined (per-unit address share, leader-only watcher user + Raft secret creation with the defer-on-failure guard, cluster-information handout), changed (cleanup + config update on watcher address change) and broken (cleanup + config update) — and the matching framework observers, exactly as in the VM charm.
  • The abstract charm constructs the WatcherEventsHandler before the config manager on VM (inert on K8s: no construction, no watcher-offer relation in the K8s charm's metadata) and constructor-injects it, mirroring the LDAP handler wiring.
  • ConfigManager.update_config no longer threads watcher_raft_address from the charm: render_patroni_yml_file sources the Raft address from the injected handler itself inside the VM-only render branch (watcher_raft_address if is_active else None, matching the charm's watcher_offer.is_active gate). The watcher_raft_address parameter is dropped from both update_config and render_patroni_yml_file; the remaining ldap/async parameters stay for their own migration phases.
  • watcher_handler is an optional keyword (default None): the production charms construct ConfigManager directly and do not import the abstract charm, so the K8s charm keeps working unchanged at the pin bump.

@marceloneppel
marceloneppel changed the base branch from 16/edge to watcher-1-port-handler September 4, 2026 21:54
…er (2/3)

Completes the port with the three relation handlers — joined (per-unit
address share, leader-only watcher user + Raft secret creation with the
defer-on-failure guard, cluster-information handout), changed
(cleanup + config update on watcher address change) and broken (cleanup
+ config update) — and the matching framework observers.

The abstract charm constructs the handler before the config manager on
VM (inert on K8s, which has no watcher relation) and constructor-injects
it, mirroring the LDAP handler wiring.

ConfigManager.update_config no longer threads watcher_raft_address from
the charm: the VM-only render branch sources the Raft address from the
injected handler (address when active, None otherwise), matching the
charm's watcher_offer.is_active gate. The parameter is dropped from both
update_config and render_patroni_yml_file. watcher_handler is an
optional keyword (default None): the production charms construct
ConfigManager directly and do not import the abstract charm, so the K8s
charm keeps working unchanged at the pin bump.

Guards the rewiring: a regression test validating update_config's
forwarded render kwargs against the real render signature (a plain Mock
swallowed the dropped kwarg), and a k8s render pass with
watcher_handler=None proving the VM-only branch never reads it.
@marceloneppel marceloneppel changed the title [DPE-11198] feat(watcher): wire the handler into the charm and config (2/3) [DPE-11198] feat(watcher): own the relation events and wire the handler (2/3) Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant