mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-13 22:26:49 +00:00
kevinveenbirkenbachandClaude Opus 4.7
99e5bef885
`_apply_one_role_special_rules()` in utils/manager/inventory.py used `bool(resolve_database_service_key(...))` to decide whether to auto-generate a `database_password` credential for a role. The resolver raises when multiple RDBMS keys are enabled — which is the correct contract for compose_volumes / container_depends_on / plugins.lookup.database (they need an unambiguous single key) but the wrong contract for inventory's credential-generation pass: variant 1 of svc-bkp-container-2-local intentionally enables both mariadb and postgres to exercise the engine-side dump path against both engines at once, and the deploy aborted with `ValueError: multiple direct database services are enabled: mariadb, postgres` during inventory generation (job 77602095377 on run 26362676803). Add a non-raising sibling helper `has_single_database_service()` that returns True iff exactly one RDBMS service is enabled, and switch inventory's call site to it. Multi-DB roles now skip the auto- generated `database_password` (which was a phantom credential for svc-bkp anyway — no schema.yml, no cross-role lookup; the role's own `04_seed-database-to-backup.yml` receives `database_password` as a caller-passed task var, not as a self-credential lookup). `resolve_database_service_key` keeps its strict raise semantics for the compose_volumes / container_depends_on / database-lookup callers, which still need a single unambiguous key. Add unit coverage for both functions (3 + 4 tests) in tests/unit/utils/roles/applications/services/test_database.py. Static check only (per operator request). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Shared Utilities (utils/)
This directory contains shared Python helpers used by custom modules and plugins.
Purpose
Use utils/ for reusable code that should not be duplicated across:
library/modules,plugins/action/,plugins/filter/,plugins/lookup/.
Typical shared utilities:
- API clients,
- validation/conversion helpers,
- path and configuration helpers,
- cross-plugin/module domain logic.
- Shared HTTP(S) connection handler for multiple modules.
- Common validation or transformation functions for user input.
- Utility functions for interacting with Docker, LDAP, etc.
- Grouped helper packages such as
utils/domains/for related domain logic.
Design Guidelines
- Keep helpers focused and composable.
- Avoid side effects during import.
- Prefer explicit function/class APIs over implicit globals.
- Keep dependencies minimal so modules/plugins stay lightweight.
Example Import
from utils.domains.primary_domain import get_primary_domain
What Does Not Belong Here
- Standalone executable modules (put in
library/). - Ansible plugin entrypoints (put in
plugins/*).
References
- Module utilities: https://docs.ansible.com/ansible/latest/dev_guide/developing_module_utilities.html
- Plugin development: https://docs.ansible.com/ansible/latest/dev_guide/developing_plugins.html