mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-12 21:56:21 +00:00
kevinveenbirkenbach
06bc856c32
The block sat under services but never behaved like a service. A service has exactly one providing role, declared with provides, so the registry can map the key to that role and consumers bind their flag to its presence. No role declares provides: mcp. There are seventeen providers and the pairing is done by allowed_consumers inside the block itself. Every rule that enforces the service model therefore needed an exemption for it: a shared-provider suppression in fourteen roles, a playwright-service-flag suppression, and two freshly added exemptions in the dynamic-flag and variants-static-override checks. Four independent rules, four escape hatches, one cause. They are all gone now, together with a bond key that only the resource budgeter reads and only for entries under services, and a wordpress addon bridge that pointed at a service block that no longer exists. The block moves to meta/mcp.yml. The applications loader maps meta/<name>.yml to applications.<app>.<name> generically, so the move needs no wiring; the file takes the same shape as meta/rbac.yml. Every config path follows, the variant overrides are lifted out of their services map, and the vocabulary module leaves the services package because it no longer describes one. roles_with_service gains an explicit topic parameter rather than an implicit fallback, so nothing silently resolves against the wrong container. Files that are otherwise unrelated to this move are included where the committed tree would otherwise keep pointing at a path that no longer resolves: thirteen vars files, eleven playwright env templates and one task file.
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