[DPE-10791] feat(config): own the patroni template and its render target (3/6)

[marceloneppel]

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.

Owning the render surface exposed a mismatch between what gets written and what reads it: the renderer wrote patroni.yaml on both substrates while K8s starts Patroni from patroni.yml, so on K8s the config subsystem drove a file Patroni never reads — a fresh pod comes up without its config, an upgraded one keeps running against a stale copy, and every later TLS, HBA or restore change silently never reaches the cluster.

Solution

• Move both charms' patroni.yml.j2 into one lib-owned single_kernel_postgresql/templates/patroni.yml.j2 that renders either substrate from a single document. The values that genuinely vary — paths, addresses, the pgBackRest config flag — are bound once at the top; conditionals remain only where the substrates really differ: the Raft section, the watcher rule, the Kubernetes-only keys and the asymmetric authentication block.
• Load it via importlib.resources instead of a CWD-relative open(); add "substrate" to the render context.
• Put the config file name on the paths object as patroni_config — patroni.yaml on both substrates, matching shipped 16/edge so the on-disk filename is unchanged across a refresh — and read it from the renderer, the K8s Pebble layer and configure_patroni_on_unit, so what is written and what is started cannot drift apart again.
• Emit the K8s data paths from the workload's major version rather than spelling 16 out. bin_dir already followed the version, so on a 17 workload the WAL, PostgreSQL-log and Patroni-log directories would have kept pointing at a 16 tree. Nothing renders differently on 16.
• Key the authentication username on absence rather than falsiness, so collapsing the three role stanzas into one loop keeps the omission to the roles that mean it — K8s drops the key for replication and superuser, VM never does.

Rendered layout changes: on VM the output loses only blank lines, with every non-whitespace line identical and in the same order; on K8s the top-level keys are emitted in one sequence rather than that charm's own. The configuration itself is unchanged, and nothing downstream reads the file as text — the config hash is taken over the Juju config options, not the rendered output — so this carries no restart. The golden matrix in #188 compares the parsed documents against the preserved pre-merge charm templates, so any changed value, added key or reordered pg_hba rule fails the suite.

Two references the charms leave undefined are preserved rather than fixed, so this stays a move: conf_path on K8s and watcher_addr on VM both render empty, exactly as they do today. The watcher's health-check rule that watcher_addr gates is unreachable in any case — the user_databases_map loop emits a broader grant for the same user and database earlier in the list, and pg_hba takes the first match.

Third (code-only) PR in the update_config stack. The golden fixtures and the per-substrate render matrix 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.

[akram09]

Seems good for me!
One thing maybe regarding how we are getting the available resources, I am not sure if the best solution would be to pass through the state. Do you think maybe we can have the K8sManager as K8sClient and use the client in the Managers ?

[marceloneppel]

Seems good for me! One thing maybe regarding how we are getting the available resources, I am not sure if the best solution would be to pass through the state. Do you think maybe we can have the K8sManager as K8sClient and use the client in the Managers ?

Yes, @akram09. The lightkube lookups moved onto K8sManager in ef52b09, but managers still reach them through state.available_resources, which is the part you're pointing at. Injecting the provider drops that passthrough along with the mutable resource_provider slot and its "not set" RuntimeError, and matches the constructor injection ConfigManager gains in #180, the next PR in this stack, for tls_manager/patroni_manager. One constraint: inject the existing ResourceProvider protocol rather than a K8s client type, since VM satisfies it through the workload and K8sManager isn't importable there. I'll do it as a follow-up so #183 stays as-is.

@dragomirp‚ this reverses the state route from #182, so say if you'd rather keep it.

[taurus-forever]

LGTM. Tnx!