PowerShell Specific Collection

Project Discussions
, ,
1

With the upcoming release of Ansible 2.22 it is now possible to run PowerShell modules through the common exec wrapper. Currently only a small subset of modules in ansible.windows support this once Support for non-Windows targets by jborean93 · Pull Request #888 · ansible-collections/ansible.windows · GitHub lands into a new release but I’m wondering whether I should take this opportunity to create a new collection like ansible.powershell that offers a supported set of PowerShell based modules that can run on Windows and Posix hosts. For example win_ping, win_powershell, win_stat, win_file, and other modules that aren’t Windows specific could be in this module under names like ansible.powershell.ping, ansible.powershell.shell, ansible.powershell.stat, etc.

A benefit to this approach is

  • a nice baseline of modules that can be used for PowerShell test targets
  • easy to see what PowerShell modules are platform agnostic and what is Windows specific
  • breaking up ansible.windows into smaller chunks and being Windows specific per its name

The downsides I see are

  • another collection Windows users now need to include
    • redirection of plugins helps but it’s still extra work on top of what people do today
  • ansible.windows needs to add this as a dependency or have it continue to include the old modules with a deprecation notice
  • just more work in general to set this up and get it included in the community package and AAP’s Execution Environments

I’m curious to see what others think about this and whether I should

  • just continue to use ansible.windows and rely on documentation to make what is and isn’t compatible on Posix
  • create a new collection like ansible.powershell (or other related name)

If I was to create the new collection it also opens up the question whether I redirect the exiting ansible.windows modules that are going into the new collection or deprecate the old ones over a long period of time. The deprecation is certainly cleaner but these are such a core set of plugins and with the builtin redirections from before the core split this may be a step too far in terms of breaking people’s playbooks.

cc @dag @briantist as you’ve worked in this area before and have some good instincts around what the community may want around this.