Skip to content

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

Draft
marceloneppel wants to merge 1 commit into
skl-01-update-config-2-paramsfrom
skl-01-update-config-3-template
Draft

feat(config): move patroni template into the lib as one substrate-conditional template#183
marceloneppel wants to merge 1 commit into
skl-01-update-config-2-paramsfrom
skl-01-update-config-3-template

Conversation

@marceloneppel

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.
  • Golden fixtures (byte-copies of both charm originals) plus a per-substrate render matrix assert byte-identical output; one divergent byte fails the suite.

Third PR in the update_config stack (base skl-01-update-config-2-params).

Checklist

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

…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 cba92af to fdf2a44 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