Skip to content

feat(config): move patroni template into the lib as one substrate-conditional template (3/6)#183

Draft
marceloneppel wants to merge 3 commits into
16/edgefrom
skl-01-update-config-3-template
Draft

feat(config): move patroni template into the lib as one substrate-conditional template (3/6)#183
marceloneppel wants to merge 3 commits into
16/edgefrom
skl-01-update-config-3-template

Conversation

@marceloneppel

@marceloneppel marceloneppel commented Jul 11, 2026

Copy link
Copy Markdown
Member

Issue

Each charm ships its own templates/patroni.yml.j2, loaded from the current working directory. The library must own the template and load it as package data so render_patroni_yml_file works regardless of CWD.

Solution

  • Merge both charms' patroni.yml.j2 into one lib-owned single_kernel_postgresql/templates/patroni.yml.j2 that branches on a substrate context var; each branch is a byte-for-byte copy of the corresponding charm template.
  • Load it via importlib.resources instead of a CWD-relative open(); add "substrate" to the render context.

Third (code-only) PR in the update_config stack. The golden fixtures and the per-substrate render matrix that assert byte-identical output live in the stack's test PR (#188), along with the minimal update to the existing render test carried here to keep the suite green.

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-01-update-config-3-template branch from cba92af to fdf2a44 Compare July 11, 2026 16:12
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-2-params branch from a7ee622 to 786d9bd Compare July 20, 2026 13:22
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-3-template branch from fdf2a44 to ef76d9a Compare July 20, 2026 13:22
@marceloneppel marceloneppel changed the title feat(config): move patroni template into the lib as one substrate-conditional template feat(config): move patroni template into the lib as one substrate-conditional template (3/5) Jul 20, 2026
@marceloneppel marceloneppel changed the title feat(config): move patroni template into the lib as one substrate-conditional template (3/5) feat(config): move patroni template into the lib as one substrate-conditional template (3/6) Jul 20, 2026
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-2-params branch from 786d9bd to ddf2305 Compare July 20, 2026 19:04
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-3-template branch from ef76d9a to d994db8 Compare July 20, 2026 19:04
…tion

Internalizes PostgreSQL parameter calculation (worker-process auto/cap
rules, wal_compression, memory-limit conversion) into the library so
ConfigManager owns the full config-build flow instead of stopping at a
TODO. Resource discovery (cpu_cores, memory_bytes) moves onto the
workload rather than a substrate-specific manager: get_available_memory
already lives there, ConfigManager already holds self.workload, and
K8sManager doesn't exist yet when ConfigManager is constructed in
abstract_charm - so the workload is the only place both substrates can
share a single no-branch call site.

K8sWorkload gains required unit_name/namespace constructor args so its
lightkube Pod/Node lookups can resolve "my own pod" without depending on
a charm object reference, mirroring what the K8s charm does today via
self.unit.name/self.model.name. lightkube becomes a real (not merely
transitive) dependency via a new k8s pyproject extra, matching the
version pins the K8s test charm already uses.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-2-params branch from ddf2305 to f9a1111 Compare July 21, 2026 17:46
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-3-template branch from d994db8 to f5d55f2 Compare July 21, 2026 17:46
The parameter-building port placed lightkube node/pod resource lookups on K8sWorkload and injected unit_name/namespace into its constructor. Both duplicate identity the state already holds and put K8s-API code on the workload abstraction, which reviewers flagged.

Move the lookups onto K8sManager, which is already K8s-only-loaded and holds the state, sourcing pod/namespace from state.peer.unit_name and state.model_name. ConfigManager reaches the value through a new state.available_resources property backed by a per-substrate provider (the VM workload, or the K8s manager), so the call site stays substrate-agnostic and lightkube never enters the VM import graph.

Behavior is unchanged: node allocatable clamped by the container limit, 403 -> DeployedWithoutTrustError. The Node lookups drop the namespace argument, which lightkube ignores for cluster-scoped resources.

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

The two charms each carried their own templates/patroni.yml.j2 and the config
manager loaded it with a CWD-relative open(), so the lib could not own the
render. Merge both copies into a single template the lib ships and loads as
package data, so the charms delete their copies in the adoption PR and the
template travels with the code that renders it rather than with each charm's
working directory.

The VM and K8s templates diverge in section ordering, whole blocks (raft,
bypass_api_service, pod_ip), path variables, and pg_hba rules, so the merged
template branches at the top level on a substrate context var with each
substrate's body kept verbatim. That guarantees byte-for-byte identical output
per substrate and avoids interleaving conditionals that could silently shift a
byte. render_patroni_yml_file now loads the template via importlib.resources and
passes the substrate the template branches on.

Golden tests render the merged template against byte copies of each charm's
original template across the full matrix of conditional dimensions (tls,
connectivity, ldap, restore/pitr, slots, peers, watcher, extra replication
endpoints, tags) and assert equality, so any divergent byte fails the suite.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel
marceloneppel force-pushed the skl-01-update-config-3-template branch from f5d55f2 to 79f2a4f Compare July 23, 2026 17:34
Base automatically changed from skl-01-update-config-2-params to 16/edge July 24, 2026 19:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant