mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-11 21:26:44 +00:00
kevinveenbirkenbachandClaude Opus 5
38675a4073
Six of thirteen failures in run 30937913632 landed on the one package acquisition path that carries no retry: package_call() built every ordinary distro-repo install with retry=None, and the enable_existing branch did the same. EXTERNAL_FETCH was attached to AUR, COPR, PPA and source builds only, and its docstring said so outright. The dichotomy that justified it - external endpoints are flaky, distro repos are not - is one the repo already rejects elsewhere: the image build wraps every dnf call in RETRIES=3, and sys-svc-ssh hand-rolls retries: 5 for apt with the comment 'nested CI egress is flaky'. Line 14 of that same file then hands the RedHat branch to the unarmoured path, which is where lam 2 and prometheus 0 died. The measurement that settles it, same task across the run: 2.98s / 5.34s / 5.63s / 6.78s / 18.09s / 20.46s / 68.41s / 367.71s (FAIL) / 769.29s (FAIL) / 815.18s (SUCCESS). The slowest run is a success - failure and success sit on one continuous tail, so the split is not mirror-up versus mirror-down. xwiki 2 hit the identical epel metadata error, same checksum, 404 from ten mirrors including dl.fedoraproject.org, and is green only because the Docker build retried it five seconds later. The three upstreams that failed - EPEL, updates-testing and www.centos.org - are exactly the three the package cache does not proxy, so the cache cannot substitute for this. test_a_plain_repository_install_is_not_retried was the defect's own tripwire and inverts accordingly. Also here because it is the same class: roles/update pinned dnf to retries=5, below dnf's own default of 10 - a hardening task that halved what it meant to raise. Co-Authored-By: Claude Opus 5 (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