New Ansible role rendering one Fediwall instance with one or more configurable walls under https://fediwall.<DOMAIN_PRIMARY>/<slug>/. Each wall's `wall-config.json` is forwarded VERBATIM from meta/services.yml.fediwall.walls[*].config — the YAML there is the single source of truth, the role's template applies no defaults. Two matrix-deploy variants ship: variant 0 inherits the services.yml default (one wall, polls all active Mastodon-API-compatible siblings via the new `lookup('fediwall_active', ...)` plugin); variant 1 overrides with two explicitly configured walls (default + mastodon-only) so the per-wall server scoping is observable end-to-end. End-to-end Playwright spec drives biber's first OIDC login on Mastodon and ldapauth-mediated form login on Friendica through the same web UI a human would use — biber's local accounts come into existence lazily on first SSO login, exactly as in production. The cross-Fediverse test is data-driven against each wall's `wall-config.json.servers`: a sibling's post is visible iff its host is listed there. Cross-cutting fixes that surfaced during the iteration ship alongside: - utils/cache + utils/templating: type-preserving render path for single-Jinja-expression scalars in `lookup('config', ...)`. `_templar_render_best_effort` always coerced its output to `str`, so a list-returning lookup like `{{ lookup('fediwall_active', 'domains') }}` collapsed to its Python repr. `_render_scalar` now detects the `{{ ... }}`-only shape and routes it through the new `_templar_render_preserve_type` helper, which returns templar's native value (list/dict/etc.) instead of stringifying. - web-app-friendica/tasks/04_addons.yml: force a `disable` + `enable` cycle for enabled addons. Friendica's `addon enable` only fires the `_install` hooks on the disabled→enabled transition, so an already-enabled-but-broken state (the addon shows up in `list enabled` but its `_install`-registered hooks are missing from the `hook` DB table) silently rejected every ldapauth login at runtime. Cycling through disable+enable reliably re-registers the hooks. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
🧩 Ansible Plugins (plugins/)
This document is the central reference for plugin types and plugin placement in Infinito.Nexus.
🗂️ Current Project Layout
plugins/
├── action/ # custom action plugins
├── filter/ # custom Jinja2 filters
└── lookup/ # custom lookup plugins
Configured plugin paths in this repository are defined in ansible.cfg:
action_plugins = ./plugins/actionfilter_plugins = ./plugins/filterlookup_plugins = ./plugins/lookup
📚 All Common Ansible Plugin Types
The table below summarizes common Ansible plugin types and their conventional directory names.
| Emoji | Plugin Type | Conventional Directory | Purpose |
|---|---|---|---|
| ⚙️ | action |
action_plugins/ or plugins/action/ |
Wrap/extend module execution behavior at task runtime. |
| 🔐 | become |
become_plugins/ |
Implement privilege escalation methods. |
| 💾 | cache |
cache_plugins/ |
Persist gathered facts and cached data between runs. |
| 📣 | callback |
callback_plugins/ |
React to play/task events (logging, reporting, notifications). |
| 🖧 | cliconf |
cliconf_plugins/ |
Define CLI command transport behavior (mainly network platforms). |
| 🔌 | connection |
connection_plugins/ |
Control how Ansible connects to targets (ssh, local, etc.). |
| 🔍 | filter |
filter_plugins/ or plugins/filter/ |
Add Jinja2 filters for data transformation. |
| 🌐 | httpapi |
httpapi_plugins/ |
API transport layer over HTTP(S), mainly for network devices. |
| 🧭 | inventory |
inventory_plugins/ |
Build dynamic inventories from APIs, services, or files. |
| 👉 | lookup |
lookup_plugins/ or plugins/lookup/ |
Resolve dynamic values during playbook processing. |
| 🛰️ | netconf |
netconf_plugins/ |
NETCONF transport integration for network automation. |
| 🐚 | shell |
shell_plugins/ |
Adjust shell command wrapping/execution behavior. |
| 🧠 | strategy |
strategy_plugins/ |
Customize task scheduling/execution strategy. |
| ✅ | test |
test_plugins/ |
Add Jinja2 tests used in conditions and templates. |
| 📦 | vars |
vars_plugins/ |
Load variables from custom sources. |
🧭 Which Plugin Type to Use
⚙️ action
Use when task execution behavior itself must be changed or wrapped.
Examples:
- centralized retry logic (
uri_retry.py), - argument normalization before module dispatch,
- pre/post task orchestration.
🔍 filter
Use for pure data transformation in Jinja2 expressions.
Examples:
- mapping/normalizing dictionaries,
- deriving computed fields for templates,
- deterministic formatting helpers.
👉 lookup
Use when a value must be dynamically resolved at runtime.
Examples:
- computing IDs from role metadata,
- resolving paths/version data,
- reading structured project data for templates/tasks.
📣 callback
Use to hook into execution events and shape output/reporting.
🧭 inventory
Use when host/group data should come from a dynamic source.
🧠 strategy
Use to alter how tasks are scheduled/executed across hosts.
📦 vars
Use to load variables from custom backends.
🔌🔐🐚 connection, become, shell
Use to customize low-level execution and privilege mechanics.
💾 cache
Use to persist facts/results across runs for performance and consistency.
🖧🌐🛰️ cliconf, httpapi, netconf
Use in network automation contexts requiring protocol-specific transport behavior.
✅ test
Use to add custom Jinja2 test operators for conditional logic.
🧪 Best Practices
- Keep plugin interfaces explicit and stable.
- Keep plugin logic focused; move shared logic to
utils/. - Add unit tests for plugin behavior and integration tests for end-to-end flows.
- Prefer deterministic outputs and avoid hidden global state.
- Document any plugin-specific task arguments in the plugin docstring and README.
🔗 References
- Ansible plugin development: https://docs.ansible.com/ansible/latest/dev_guide/developing_plugins.html
- Ansible plugin index (all types): https://docs.ansible.com/ansible/latest/plugins/plugins.html
- Ansible
ansible-docplugin types:ansible-doc -t ...