mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 19:56:53 +00:00
kevinveenbirkenbachandClaude Opus 5
d3610af31f
`disable=lam` aborted the local deploy of web-app-openbao with "`disable` conflicts with the current inventory state", and web-app-moodle carries the same construction in two of its variants. The writer and the conflict check disagreed on scope. apply_services_disabled walked `find_roles_with_service`, the roles whose meta/services.yml declares the key, so neither role was in that set for `lam` and nothing was written. find_services_disabled_conflicts walks every deployed app's host_vars instead, found the `lam` block the variant had baked, and refused the run. Dropping `lam` from the list is not an answer either: the round then deploys web-app-lam although ldap is off. The writer now also flips a key it finds in host_vars under an app whose role does not declare it, and only the flags that are already in that block. It never creates a key or a flag, which is what `_declared_toggles` exists to prevent: compare_application_keys rejects a host_vars key the role contract does not carry. Overwriting a value the variant already wrote introduces nothing, so that rule is untouched; test_skips_app_whose_role_does_not_define_service still passes and pins it. The alternative the TODO proposed, declaring `lam` in meta/services.yml with the `'web-app-lam' in group_names` flags, is the worse trade: a consumer entry is resolved through the service registry, so it would bind web-app-lam and its whole closure into every round that carries openbao or moodle, for a key both roles read only to gate a Playwright spec. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>