On Tue, Jul 12, 2022 at 10:30:58AM -0700, Brian Coca wrote: > Actually I was already thinking of spliting _modify_module, for one, it > should not need/handle/know about become_kwargs and we should eliminate the > passing of these, which is kind of the opposite direction of your > proposal.
I requested a more extensible ActionModule for one actual use-case where code needs to intervene over both `become_*` and `modules_*` variables (before these get encoded). There are actual benefits in doing so and I suggested a non-intrusive patch for this. (I'd be a bit... abrupt if a stance like "xxx should not need/handle/know about yyy" would lead to disregard an actual and reasonable user request) I made a case for a dynamically altering some of a module's arguments according to `become` and that the existing code path for this must not only be absolutely preserved but also made more easily overridable/changeable/hookable. To be more precise about my particular case (even though one can easily think about many more): This one (Ansibhook น) is an attempt to harden Ansible privileged command execution to make it safer for use as a project auto-deployment tool. That means tweaking some modules' arguments **according** to the become_method in order to make the `sudo` requirement of some module more granular than it is currently (whole `python -m` module execution vs only the `subprocess.Popen()` part) And a way to tweak `run_command()` in an elegant and generic way depends on the above-mentioned ability to access both `become_*` and `modules_*` variables before the AnsiballZ creation (and add knowledge of the `become_*` context to the module) I hope this will help to better understand the initial request. > As for action plugins, they already do too much and have too much > information for their needs, we are looking at moving these things into a > more generic/changeable 'executor' that should handle those parts and leave > the 'action plugin' to just coordinate local and remote actions w/o having > to deal with the details as they do now. If "generic" really means "more open to extensions, overrides, user freedom and imagination", then I'm all for it. Please let me know if a PR appears improving the situation. Regards น https://gitlab.com/drzraf/ansibhook -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/20220712225402.GA1571293%40acer.
