Windows modules grouping

Archives Ansible Developer
1

Hi all,
As the number of Windows modules continue to grow, should we discuss possibly grouping these the same way we do with modules for linux systems? Any thoughts?

2

I think that tackling this sooner than later is probably a good idea. Maybe instead of Windows/group we have a windows subtype in each group I.e utilities/windows??

Thoughts?

3

I’d sort of like the windows folder to disappear and just have the modules in with the other existing groupings, but then have a visual clue that each module is either targeting windows, *ux (and perhaps even local/virtual). But there are probably things that only make sense on windows - registry-related stuff, or things like the ngen module, so probably need a place for those anyway.

4

I think that:

  1. We shouldn’t disturb the existing folder structure for *nix modules, that would just get too messy
  2. I’m not sure the same folders apply to Windows as to nix. For some stuff the structure fits (IIS modules go into the web infrastructure folder) but for loads of stuff it won’t (especially as we’re getting more and more specialized modules in modules-extra).
  3. Finally (and maybe more important), the modules that work across OSes (such as setup, template, etc need to be better clarified (i’m thinking in terms of the doc pages here)

Just thinking out loud here, I don’t have any master plan behind any of this :slight_smile:

5

I’m actually worried about the “shared” actions/modules- for the simplest use cases, the args more-or-less line up, but when things start getting more complex, they won’t necessarily. The likelihood of useful mixed Win/Linux plays (ie, that share the same tasks) seems really low for real-world use cases, so saying “just use win_template/win_script/win_X” and documenting them independently seems like it leaves a better door open to forking docs and/or implementation when the time comes.

For example: none of the win_(file|copy|template) modules currently support owner-setting, DACLs/SACLs + inheritance/recursive set. I’ve already run into situations where it’d be nice if they did, and I’ve been playing with different YAML representations to cover at least sane cases that won’t require folks to speak SDDL. I’ve also been wishing for a better way to manage paired actions/modules in core/extras (eg, get the paired actions and modules like copy/stat/template in the same repo). I think the 2.0 plugin search mechanism makes this possible, so might be a good time to think about that as well. (sorry for the scope creep)

-Matt