Monolithic Module Scripts

[sandinak]

Hey Mike,
Very nice work here!!! I am curious about something. I was able to use the role when inventory points directly at the routers as noted in your docs, however, I've got a situation where i am updating router config using delegate_to: "{{groups['routers'][0] }}" .. which doesn't work so well with the current incarnation.

I cheated outrageously and used ANSIBLE_KEEP_REMOTE_FILES, AnsiballZ_uci.sh and re-created the openwrt_uci.sh as the result of the monkey-business ... and it works cleanly w/o having to use the plugins or wrapper.sh. Now my code looks like this:

- name: create host record in uci
  delegate_to: "{{groups['routers'][0]}}"
  openwrt_uci: 
    command: section
    config: dhcp
    type: host
    find_by: 
      name: "{{ inventory_hostname }}"
    value: 
      name: "{{ inventory_hostname }}"
      mac: "{{ macaddresses }}"
      ip: "{{ ipaddress | default(ansible_default_ipv4.address) }}"
  notify: uci commit

So I am curious .. why not just use the result as scripts in the ANSIBLE_LIBRARY directory to be used on the remote hosts, vs the manipulation to create them on the fly. I get the re-use of code argument.. however since this is a repo .. that should be easy to manage with a build script for the files.

If you're intersted in this approach .. then users can just replicate your library dir into theirs ( or include it, gilt it in ..etc.. ) and have a much simpler deployment... and I'll be happy to create that PR. Thanks.

[gekmihesg]

The initial idea was not to have to think twice, whether this current host is a OpenWRT system or something with Python. In the case of the uci module, that doesn't make much sense. In hindsight, looking at the roles based on this project I wrote, it would have been perfectly okay to have all modules named openwrt_* instead. And yes, working around the code duplication should be possible in some other way as well.
Feel free to try this, but be aware that there is some other stuff going on by reusing the default Ansible names. Some modules have a client side counterpart which kicks in automatically. Also, maybe the collections mechanism introduced a couple of versions ago provides some completely different approaches to solve this.