Skip to content

feat(config): port PostgreSQL parameter building + resource introspection#182

Draft
marceloneppel wants to merge 2 commits into
skl-01-update-config-1-peer-accessorsfrom
skl-01-update-config-2-params
Draft

feat(config): port PostgreSQL parameter building + resource introspection#182
marceloneppel wants to merge 2 commits into
skl-01-update-config-1-peer-accessorsfrom
skl-01-update-config-2-params

Conversation

@marceloneppel

Copy link
Copy Markdown
Member

Issue

update_config builds PostgreSQL's bootstrap.dcs.postgresql.parameters from the unit's CPU and memory, which both charms compute per substrate. This step ports the parameter builder and the substrate resource introspection it depends on.

Solution

  • managers/config.py: _build_postgresql_parameters with the _calculate_max_* helpers and _calculate_worker_process_config(cpu_cores).
  • Workload get_available_resources() -> tuple[int, int] — VM reads os.cpu_count() and available memory; K8s reads the node/pod via lightkube and raises DeployedWithoutTrustError on a 403 ApiError.
  • New k8s optional extra (lightkube, lightkube-models) mirroring the existing vm extra, plus a regenerated uv.lock.

DeployedWithoutTrustError is raised here and caught at the charm/event layer in the charm-adoption PR (managers-raise convention). Second PR in the update_config stack (base skl-01-update-config-1-peer-accessors).

Checklist

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

…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>
Porting the charm's config code into the lib deleted the charm tests that
guarded these paths, leaving them unasserted lib-side:
- get_available_memory: MemTotal kB -> bytes conversion, and empty input -> 0.
- _calculate_worker_process_config with zero cores: auto -> "0", not the
  8-fallback.

The ported code is faithful (verified byte-for-byte), so these are regression
insurance for this branch's resource introspection, not a behaviour change.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
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