Krikri::AddHostActionPlugin
Inherits Krikri::ActionPlugin < Reference < Object
add_host: (ansible.builtin.addhost) as a controller-side action plugin -
real Ansible's own add_host is action-plugin-only (no target-side
module exists), and its entire effect is a controller-side inventory
mutation, so a remote round trip would be meaningless. The plugin
mutates the ONE shared Inventory instance every play's host-pattern
resolution reads from (krikri-playbook.cr's own inventory local,
same object handed to every TaskExecutor) - that mutation is the whole
feature: a host added in play 1 only shows up when play 2's hosts:
pattern is resolved because play 2 re-calls Inventory#get_hosts on the
same object. It is deliberately NOT added to the current play's own
host list (already fixed before the task ran) - real Ansible behaves
the same way, verified.
Out of scope on purpose: exact host-var precedence layering for the new host (its vars are plain host vars, same as any inventory-parsed host), delegate_to: against a dynamically-added host, and inventory plugins re-running over the mutated inventory.
Constants
Instance methods
Execute action on controller Returns: modified params to send to remote plugin, or nil if action failed