feat(refresh): own the refresh-aware unit status gate (2/6) - #264
Draft
marceloneppel wants to merge 1 commit into
Draft
feat(refresh): own the refresh-aware unit status gate (2/6)#264marceloneppel wants to merge 1 commit into
marceloneppel wants to merge 1 commit into
Conversation
Add the RefreshManager: it constructs the substrate's charm_refresh object (Machines/Kubernetes with the charm-specific classes, including the K8s untrusted-app and teardown handling) and owns the refresh-aware unit status handling the two charms duplicated - the set_unit_status priority gate with the .last_refresh_unit_status.json caching and the collect-unit-status reconciliation, deduplicated onto the workload.is_patroni_running() check (the K8s charm passed it explicitly, the VM relied on the default). The refresh-aware gate becomes the library's set_unit_status bridge, so the status writes the managers already route through the charm now respect the refresh priority interplay. set_default_unit_status and set_app_status are new bridges for the reconciliation's clear-status branch and the leader's async app status - both owned by charm-side modules until they migrate.
2 tasks
marceloneppel
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
Part of the refresh module migration from the PostgreSQL VM and K8s charms' 16/edge branches into this library. Stacks on #257.
Solution
Adds the
RefreshManager: it constructs the substrate'scharm_refreshobject (Machines/Kuberneteswrapping the charm-specific classes, including the K8sKubernetesJujuAppNotTrusted→can_set_app_status = FalseandUnitTearingDown→ teardown-exit handling) and owns the refresh-aware unit status handling the two charms duplicated:set_unit_statuspriority gate with the.last_refresh_unit_status.jsoncaching, deduplicated onto theworkload.is_patroni_running()check (the K8s charm passed it explicitly, the VM relied on the default), andset_default_unit_statusbridge (the charms'_set_primary_status_message/_set_active_status) and the leader's app status to aset_app_statusbridge (both owned by charm-side modules until those phases migrate).The refresh-aware gate becomes the library's
set_unit_statusbridge, so the status writes the managers already route through the charm now respect the refresh priority interplay.update_configgains therefreshkeyword the VM refresh flow threads through to the existingConfigManagersnap-revision gate.Unit tests follow in #265. The conftest shunts the
charm_refreshentry points and pins a minimalrefresh_versions.toml, mirroring the charms' unit conftests.