You could call the copy or template module earlier in your playbook, which of course is also doable if you are just using the API directly (though very very very few people do this).
There is no way for a module to loop back to the control machine and say “before you continue, run this”
You might want to look at the SSH key module (authorized_key) which actually passes down the key as a string where in your playbook you could just use a Jinja2 key={% import path/to/keyfile-%} or however that looks to load the string source into the action string.
The solution to make Jinja2 “read” the file and set the “key” variable with the content of the file seems to be the better option for now but I can’t make it works 
I tried something like :
action: apt_key key=“{% import file.key %}” uid=“key uid”
but it does not work. Code between {% %} is not interpreted. How can I make Jinja interpret the import into a playbook ?
Do you plan to implement a way to execute some part of module code locally (with access to the connection, to transfert files for example) ? I think, this would allow to have the same capabilities as internals modules like template, copy, … for externals modules.
WDYT ?
"Doesn't work" ... Doesn't work how?
How did you define "file?" Can you show me? There's probably
something subtle to do.
To what I think was your last question -- Ansible is not going to
allow remote nodes to make decisions about how to control the central
machine, no. Seems very wrong, dangerous, and complicated to do so.
I'd prefer we concentrate on figuring out how to manipulate Jinja2 in
this case than speculate on
what if the architecture was the antithesis of itself.
“Doesn’t work” … Doesn’t work how?
How did you define “file?” Can you show me? There’s probably
something subtle to do.
Here is more details : https://gist.github.com/3275616
There is the apt_key module, a typical playbook that uses the apt_key module and the output of test-module.
As you can see, the “key” argument is not processed by jinja2.
The result is the same with the actual ansible-playbook command line.
To what I think was your last question – Ansible is not going to
allow remote nodes to make decisions about how to control the central
machine, no. Seems very wrong, dangerous, and complicated to do so.
I’d prefer we concentrate on figuring out how to manipulate Jinja2 in
this case than speculate on
what if the architecture was the antithesis of itself.
I was not thinking about controlling central machine from remote nodes but instead I was thinking about executing a module in multiple phases :
- a first part of the module would be executed on the central machine for each remote nodes, for example with something like this : ./mymodule $JSON_ARG $NODE_CONNECTION_PARAMS
- a second part of the module would be the same as of now and would be executed on remote nodes
In this scenario :
- the central machine still have control over remote nodes and not the opposite which, I agree with you, has something wrong
- in the first phase, the module can prepare remote nodes from the central machine (like uploading some resources needed in the second phases or pre-processing files with jinga2)
- internal modules could be implemented the same way as other modules