The version-source update in #1146 moved the bigbluebutton/docker ref from v3.0.23 to v3.0.39. That tag changes three things the role did not handle, and it exposed a fourth defect in compose_file_args. 1. generate-compose renders etherpad and bbb-pads only behind USE_INSECURE_ETHERPAD and otherwise emits bbb-shared-notes-server with a `build:` block and no `image:` (upstream adds the image only after the tag, in 9a6a9a9a4c). compose_mods drops `build` only where an image is set, so the guard "Fail if any service still builds locally" stopped every BigBlueButton deploy (main run 39749899667, Nextcloud#11: `rc: 0`, `stdout: ' build:'`, bootstrap_compose_project.yml:35). meta/services.yml now pins alangecker/bbb-shared-notes-server:v3.0.39, compose_mods takes `pinned` (BBB_PINNED_SERVICES, every service the role config pins an image for) and drops their `build`, and the etherpad leftovers go (ep_redis_publisher patch, etherpad postgres entrypoint and initdb hook, etherpad database tasks, ETHERPAD_* env, etherpad_api_key secret). 2. The notes server connects to postgres once at start and exits with 2 when it is not up yet; upstream gives it no restart policy. The override sets the role's restart policy, so it retries until postgres accepts connections. 3. Greenlight moves from v3.8.0 to v3.9.0.1, which sets `config.hosts = URL_HOST`, and the template passes `URL_HOST: https://${DOMAIN}`. Rails compares hostnames, so every request was blocked (`Blocked hosts: bbb.talk.infinito.test`, 403). Greenlight documents URL_HOST as the bare hostname; the override sets it to the role domain. 4. compose_file_args decided whether a role ships a compose override by templating "{{ application_id | abs_role_path_by_application_id }}" through the templar. ansible-core 2.21 does not render an untrusted string, so the check saw the literal and always returned False: the CA override generation and the pull handler never read BBB's compose.override.yml. That was harmless while compose.yml alone was valid; with the notes-server image living in the override, `compose config` failed ("has neither an image nor a build context"). The check now resolves the role path for the application id it is given. BBB is the only role that ships an override, so no other role's file list changes. Existing installations drop the etherpad and bbb-pads containers on the next `compose up --remove-orphans`; the old `etherpad` database stays in PostgreSQL untouched. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Ansible Plugins (plugins/) 🧩
This document is the central reference for plugin types and plugin placement in Infinito.Nexus.
Not to be confused with application addons. This
plugins/directory holds Ansible plugins (action / filter / lookup) that extend the automation engine itself. Some applications also call their own extensions "plugins" (e.g. Nextcloud, WordPress). Those application-level extensions, whatever the app calls them natively, are declared through the unifiedmeta/addons/contract, documented in Unified Addons. An app "plugin" is an addon; an Ansible plugin lives here.
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: docs.ansible.com
- Ansible plugin index (all types): docs.ansible.com
- Ansible
ansible-docplugin types:ansible-doc -t ...