class

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

GROUP_PARAMS = {"groups", "group"}
NAME_PARAMS = {"name", "hostname"}

Instance methods

execute

Execute action on controller Returns: modified params to send to remote plugin, or nil if action failed

Source