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.
In my mind, it makes sense to have these modules that support PowerShell 5+ (working on both Windows and POSIX) into a separate collection given they’re not Windows specific anymore. However, at the same time as you rightly point out, it has maintenance and UX downsides. It would also mean ansible.powershell would need to be certified separately to, adding to the maintenance.
I could help with maintenance if needed. I have experience with writing quite a bit of PowerShell too. Let me know if I can help
Somewhat related, that post is more about how we can try and improve the documentation in general for all collections and wanting to indicate requirements in a more structured manner.
It’s definitely more work to set up the collection but in my mind the maintenance going forward is probably going to be easier. It reduces the load on ansible.windows and the number of tests it needs to run which is always a good thing and focuses this hypothetical new collection on a specific set of tasks rather than lumping it in with “Windows”.
Certification is another question that I do need to follow up internally but based on previous attempts to split up ansible.windows and promote modules from community.windows to a supported/certified collection I don’t see any immediate blockers.
The UX side is probably the part I’m more concerned with. Using redirections in ansible.windows to point to this new collection certainly papers over this a bit more but modules like win_ping, win_file, win_stat, win_powershell are pretty fundamental that any change in where they are located could have some unforeseen consequences. From my perspective if we were to go ahead with this I see 3 possible options around this
Do nothing, keep the ansible.windows modules as is and maintain both for the foreseeable future
Add a redirection so ansible.windows.win_ping -> ansible.powershell.ping
Same as above but add a deprecation for the redirection so it is not kept around indefinition
My money would be on 2 with maybe adding the deprecation years into the future if there is a desire to remove the dependency that ansible.windows would have on this new collection at runtime.
Appreciate it, will definitely let you know if I do get started on this.
I actually think this is the better option. I know we’re concerned about backward compatibility and breaking existing things, but at some point something’s gotta give if we want to improve and move forward, and papering over the changes indefinitely is probably more likely to have unforeseen consequences than not.
I can understand if the deprecation date/version is years in the future, but maybe like.. 2 years max and set right away so the warnings are around for a long time.
To me this isn’t much of a downside. Once you need to include any external collection, adding more just isn’t a big deal imo.
I’ll be honest I don’t love the collection being ansible.powershell, much in the same way that I don’t love windows as a grouping for a collection or the win_ prefix on modules. We wouldn’t really make other collections like ansible.python or ansible.linux.
I mean I get why, I understand the history we’re working with and all that, and I have no better suggestion whatsoever so I’m not really rejecting the idea. It’d be nice if one day non-python runtimes were less of the distinction they are now.
mini rant aside: a new collection makes sense where we are today, and especially as it relates to what will potentially be new testing challenges, it’ll probably be nice to have that separation.
cc @lowlydba who maintains the sqlserver collection, which is already an OS-agnostic set of PowerShell modules (and can maybe finally run on Linux without the hacked core plugins we put together )
I can understand this perspective and typically I would agree, I’m just quite reluctant here due to how core these modules are to using Ansible on Windows. The removal of the redirection would result in playbooks that have worked since the 2.0 days ultimately breaking and while things do change and removing tech debt is good I’m unsure whether it’s worth it in this scenario or at least not until this hypothetical new collection has been around for longer.
In this case this would be the first dependency to ansible.windows. It’s not a deal breaker but with Galaxy and the tooling being what they are it’s just extra work and potential issues where we don’t have today.
I can agree with this but I keep coming up short on a potential name to use here. The modules that would be included in this are meant to be “core” modules that provide a base set of functionality that works cross platform so there isn’t really a grouping that is ideal except the language. As you’ve said we don’t really have a good story around language. We could instead try and lump them together with the other Python based modules and use the prefix pwsh_ like ansible.builtin.pwsh_ping but
I doubt core will want to bring these back in
Just trades the win_ prefix for pwsh_ prefix anyway
As a side note we do have ansible.posix already which contains modules that we didn’t want to keep in core but still had to “support” them.
One of the main drivers behind this was from some of the issues I had with testing the existing PowerShell modules across the various platforms. I found that I needed a core set of things like stat, file, command/shell, tempfile like modules but either had to fix up the existing win_ ones to fix whatever Windows specific logic it had, use when conditions to change the module to run with, or have 2 different test targets and duplicate the tests.
)