Skip to content

feat(config): complete update_config with API apply, restart engine, and bridges#180

Draft
marceloneppel wants to merge 2 commits into
skl-01-update-config-3-templatefrom
feature/migrate-update-config
Draft

feat(config): complete update_config with API apply, restart engine, and bridges#180
marceloneppel wants to merge 2 commits into
skl-01-update-config-3-templatefrom
feature/migrate-update-config

Conversation

@marceloneppel

@marceloneppel marceloneppel commented Jul 11, 2026

Copy link
Copy Markdown
Member

Issue

The capstone of the migration: the update_config orchestration itself — apply the Patroni REST API config patch, decide reload-vs-restart, and persist the config hash — plus the charm-owned bridges it calls back into.

Solution

  • managers/config.py: update_config orchestration wiring apply_api_config, handle_restart_need, is_tls_enabled, is_restart_pending, generate_config_hash, and config-hash persistence.
  • Reload/restart bridges as constructor-injected charm-owned callables (request_restart, refresh_endpoints, restart_services), matching the TLS migration's collaborator-injection pattern; declared @abstractmethod on the abstract charm and stubbed per substrate.
  • VM-only standalone connect-gate; K8s goes member-started → apply_api_config directly.

Final PR in the update_config stack (base skl-01-update-config-3-template). Charm adoption — deleting the charm-side copies, catching DeployedWithoutTrustError, wiring the bridges — follows in per-charm PRs once the lib is released.

Checklist

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

@marceloneppel marceloneppel changed the title feat(config): migrate update_config subsystem into the library feat(config): complete update_config with API apply, restart engine, and bridges Jul 11, 2026
@marceloneppel
marceloneppel changed the base branch from tls-4-tests to skl-01-update-config-3-template July 11, 2026 01:42
…and bridges

The library now owns the full config-update flow (steps 3-10) instead of the
charm. update_config renders, applies Patroni-controlled parameters via the API,
runs the TLS/pending-restart decision engine, honors the VM snap gate, and
persists the config/user hashes -- all in the lib.

The substrate-tangled pieces of the restart trigger, endpoint refresh, and
monitoring/LDAP service restarts ride charm-side through three injected bridge
callables (request_restart, refresh_endpoints, restart_services) until their own
migration phases, so the two HIGH-risk substrate diffs in the restart trigger
(VM pops postgresql_restarted; K8s updates the metrics scrape job) stay out of
the library. is_tls_enabled and generate_config_hash internalize; user_hash
stays injected. The config hash is byte-compatible with the charm's, so charm
adoption does not force a spurious restart.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
update_config always renders patroni.yml with enable_tls=is_tls_enabled, but
the orchestration tests mocked render_patroni_yml_file without checking that
kwarg, so a regression hardcoding or inverting the TLS flag would still pass.
Pin that the flag reaches the render call for both the enabled and disabled
states.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-3-template branch from cba92af to fdf2a44 Compare July 11, 2026 16:12
@marceloneppel
marceloneppel force-pushed the feature/migrate-update-config branch from 08f5993 to 40752dd Compare July 11, 2026 16:12
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