| 7 Jul 2022 |
 weiyentan | In reply to @briantist:libera.chat
weiyentan: sure; this also may not be the best method for your use case Oh. In my use case I think I will follow bcoca way through the task . But I have learnt how to write windows ansible libraries using powershell , I want to extend it to write plugins and libraries in python. Particularly action plugins because i can see value in that | 16:58:28 |
 briantist | yes, definitely follow bcoca's advice and avoid writing an action if you don't need to! | 16:59:06 |
| weiyentan | What about this use case. Let's say i want to create reporting (let's say in excel or word. I could use the module setup or other 'facts' type module. Then In the action plugin I could use the docx or excel python modules to create the report with? | 17:03:57 |
| briantist | I'm not sure I have enough information to say... generally just remember that a module execution always has two portions: the controller side (action) and the remote side (the module). If you don't provide an action, a default is used (`normal.py`, or `async.py`, or whatever, I'm probably messing this part up a bit). The action is good when you need to run part of all of your task on the controller, or more finely control | 17:11:39 |
| briantist | how/when the remote module portion is executed, or when you need to coordinate the execution of multiple remote modules and maybe make some coherent set of results out of them. The `template` "module" is a good example, where the templating happens on the controller, and the `copy` (I think?) module is used to for putting the result in place (oversimplification...) | 17:11:39 |
| weiyentan | The second part is the use case I am referring to | 17:13:05 |
| weiyentan | Need to get 'facts' of multiple nodes then i want to get those facts and generate a report out of it | 17:13:44 |
| briantist | the multiple nodes part sounds suspect; ansible is running each task against a specific host | 17:17:15 |
| briantist | I don't recommend trying to muck with that in an action (or otherwise) | 17:17:30 |
| weiyentan | Yeah I would need to because I would need to get a task for each host | 17:22:22 |
| weiyentan | Or fact... | 17:22:42 |
| weiyentan | But I see where you are going | 17:22:49 |
| weiyentan | The module that would be run on the host is the just setup or another fact. But the documentation part would run as a plugin? As everything is collated on the controller | 17:25:33 |
| briantist | to me it sounds like you'd be better off running `gather_facts` on each host as usual, and then maybe doing a `run_once` task or a new play that accesses the variables from the other hosts to build a report one time. That report creation could be a custom module, but wouldn't need any action plugin as long as you could count on the invoker to pass in all the things needed. | 17:25:53 |
| briantist | I suppose an action plugin could internalize the gathering of all those vars from the controller side, and then it could do all the work on the controller too, or pass them to a module (which at that could run local or remote) | 17:26:39 |
| briantist | not sure how good of an idea that is though | 17:26:45 |
| weiyentan | If it was done as a run_once. Would the host be localhost? | 17:28:18 |
| briantist | no, it would be the first host that Ansible would have executed on | 17:28:43 |
| briantist | so it may not be predictable | 17:28:49 |
| briantist | but you could `delegate_to: localhost` to do that | 17:29:00 |
| weiyentan | But then if it is delegate to localhost isn't that what a plugin is for? | 17:29:30 |
| briantist | not exactly, no, the module is still executed in a fork (so not in the controller), it's just that the host happens to be the same host where you're running ansible | 17:30:04 |
| briantist | and it uses the `local` connection | 17:30:14 |
| weiyentan | Well. In the use case I have. I have the dates gathered from the remote hosts. The report is generated on the controller | 17:31:15 |
| weiyentan | * (null) | 17:31:27 |
| weiyentan | I thought it is nice to have ansible be the controller in situations like this where it is the central point | 17:33:03 |
| briantist | I'm just saying, a module can be executed on a remote host or on the controller (on, not IN, so not in the same context as a plugin). A plugin on the other hand has access to a lot more "stuff" (often stuff you shouldn't really be accessing), but its code doesn't execute remotely. It can be a lot easier to reason about modules, since they simply take inputs and produce results, and that can keep you out of trouble | 17:33:48 |
| briantist | most of the time, executing ON the controller, and not in the controller process, is good enough | 17:34:05 |
| briantist | for your report generation, I'd wager that is true in this case too | 17:34:23 |
| weiyentan | I saw the example on the action plugin and example the executemodule method. It had the example of facts and generating something back. I really liked that notion because the information came back as a dict which I can then process.
How would that work similarly if it was done as a module Running on the controller instead of the process as you say? Because I feel the workflow will be different | 17:38:59 |
