20:00:38 <jborean93> #startmeeting Ansible Windows Working Group
20:00:39 <zodbot> Meeting started Tue Nov 15 20:00:38 2022 UTC.
20:00:39 <zodbot> This meeting is logged and archived in a public location.
20:00:39 <zodbot> The chair is jborean93. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:39 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:49 <jborean93> #chair nitzmahone
20:00:49 <zodbot> Current chairs: jborean93 nitzmahone
20:01:09 <jborean93> #info https://github.com/ansible/community/issues/644 Agenda
20:01:26 <jborean93> nothing on the agenda
20:01:29 <jborean93> so straight into
20:01:32 <jborean93> #info Open Floor
20:01:57 <jborean93> beh forgot my commands
20:02:01 <jborean93> #topic Open Floor
20:03:13 <nitzmahone> o/
20:03:13 <briantist> hey
20:03:17 <jborean93> hey
20:04:46 <jborean93> It's nothing official yet but we've been kicking around the idea of splitting the domain modules into a new support collection, potentially called `ansible.win_domain`
20:05:26 <jborean93> It would move the existing stuff in `ansible.windows`, like `win_domain` and `win_domain_controller` into there as well as the `win_domain_*` stuff in `community.windows`
20:05:39 <briantist> that's cool! personally I would like to move away the `win_` prefix generally
20:06:09 <briantist> `ansible.active_directory` ?
20:07:21 <jborean93> That's a nice suggestion, my only qualms is the length of it. Still not like `win_domain` is that much shorter
20:08:08 <nitzmahone> Yeah, and at least for the collection itself, might cause some confusion if people think they can run the modules on Linux, but I guess ideally someday that'd actually be the goal, so hopeful naming? ;)
20:08:29 <jborean93> The other question is how would we potentially deal with the Linux side. There's plenty of ldap modules that could theoretically do the same thing but from Linux
20:09:02 <jborean93> do we keep with the `ansible.<ns>.win_user` or just stick with `ansible.<ns>.user` and hope that we can have both `user.ps1` and `user.py` in the future
20:09:32 <bcoca> win.dc. ...
20:10:43 <jborean93> There's also the option of using my PSOpenAD module for Linux in a ps1 like what nitz was playing with the MS SQL side ages ago but that's pwsh 7+ only
20:10:48 <nitzmahone> Well, I meant cross-platform PS as the aspirational part, but IIRC those are still currently leaning on a lot of management cmdlets/WMI stuff that's not available on Linux
20:10:56 <nitzmahone> yeah
20:11:34 <jborean93> I suppose it won't hurt to have a `user_ex` or `user_v2` in the future that might be cross platform and we actually support pwsh then. We can slowly deprecate the older stuff if need be
20:12:10 <briantist> well, yeah there's a lot to think about re: cross-platform and naming for modules in particular
20:12:49 <briantist> and you all know I'm a fan of having both powershell and python modules being cross-platform (`lowlydba.sqlserver` is already a collection with cross-platform powershell modules)
20:12:56 <jborean93> very much so, probably shouldn't stop us from doing it
20:13:51 <briantist> but for now, let's at least not add another `win_` prefix in a collection name, where it's hard to change
20:14:35 <jborean93> true, `ansible.active_directory` or maybe even `ansible.ad` if we think people would understand that acronym
20:14:57 <nitzmahone> heh, "you have a module for controlling ads on Ansible?"
20:15:01 <jborean93> lol
20:15:16 <jborean93> Well there's bound to be some telemetry on the pwsh side :)
20:15:24 <nitzmahone> The only other concern I have is maybe around some way to make it clearer in the docs that this module requires Windows
20:15:54 <nitzmahone> (shouldn't stop us from naming it sans `win_` prefix, but IIRC it's not super clear in the existing docs)
20:16:13 <nitzmahone> https://docs.ansible.com/ansible/latest/collections/ansible/windows/index.html
20:16:32 <jborean93> aren't there attributes you can put on the module docs now for that?
20:16:47 <briantist> yes!
20:16:52 <nitzmahone> Yes, bcoca could tell you if there's something apropos there
20:17:21 <jborean93> I've seen it before for a few things but not sure how to define it slash if there's a windows specific one
20:17:23 <bcoca> platforms
20:17:24 <nitzmahone> I don't think we set any of those on the Windows modules yet
20:17:38 <bcoca> ^ attribute tells you what platfomrs module/plugin is designed for
20:17:38 <briantist> there's a lot of discussion in #ansible-docs today about custom attributes, but yeah there might already be one
20:17:39 <jborean93> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html#attributes
20:17:45 <jborean93> looks like there is
20:17:46 <briantist> ah right `platforms`
20:18:05 <jborean93> that makes me less apprehensive about dropping `win_` from the module name itself
20:18:19 <bcoca> jborean93: that was part of plan with attributes
20:18:25 <bcoca> not needing 'win_
20:18:26 <jborean93> https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/setup.py#L88-L96
20:18:27 <bcoca> everywhere
20:18:30 <jborean93> sweet
20:18:47 <briantist> yeah, I'm not even advocating _definitiely_ dropping it now, but having the attributes available goes a long way with that!
20:18:48 <bcoca> once weh have 'controller side' reading we can even warn/select modules according to platform
20:18:56 <briantist> dropping it now *in modules
20:19:00 <bcoca> in time, we are not there yet
20:19:12 <bcoca> 'platform' is also a plan nitz and i have for 'sane defaults'
20:19:25 <bcoca> so its not hard at all to configure settings for targets anymore
20:19:44 <nitzmahone> *sigh* someday :D
20:19:48 <jborean93> will definitely keep this all in mind, it's not officially going to happen as of yet but the wheels are starting to turn so just trying to cover the basics
20:19:58 <bcoca> nitzmahone: we getting there, i keep adding pieces every release
20:19:58 <jborean93> heh platform, totally not something that was meant to happen in 2.3 :)
20:20:03 <nitzmahone> <.<
20:20:27 <nitzmahone> Oh come on, I think it was 2.7 or 2.8 at least :D
20:20:34 <bcoca> jborean93: many things ... collections were also meant to happen in 2.0 (just had not named them that yet)
20:21:04 <jborean93> heh
20:21:07 <bcoca> nitzmahone: no, 2.3/2.4 might be right for when we started discussions, might not have named ti ';platform' till 2.7 though
20:21:38 <bcoca> some changes are easy and get added right away .. others take a lot of time and thought .... data tagging ...
20:21:58 <jborean93> it'll get there eventually
20:22:09 <jborean93> it's a tricky thing to get right, especially with how things are set up
20:22:36 <bcoca> backwards compat is biggest issue .. otherwise i would have redone setup.py into 200 modules at thsi point
20:22:49 <nitzmahone> We could've YOLOd that a year or two ago, but the fallout would probably have been massive :D
20:23:05 <bcoca> but i keep putting building blokccs in place (gather_facts action .. multiple facts modules from config)
20:23:18 <nitzmahone> heh, that one just saved us again this morning :D
20:23:24 <bcoca> ^ that is also part of platform
20:23:48 <bcoca> nitzmahone: that is the trick, start adding building blocks that are usefule on their own and for other purposes
20:24:09 <nitzmahone> no real easy way to do that with data tagging, unfortunately
20:24:15 <bcoca> agreed
20:24:49 <bcoca> but platform is both a lot harder and easier .. since there are many 'blocks' i can add that are worth adding just by themselves
20:25:14 <bcoca> attributes is another example
20:25:32 <bcoca> goes both for platform and  controller side argspec/module introspection
20:25:49 <bcoca> right now its just 'doc addition' which is useful to let users know quirks in behaviour
20:26:00 <bcoca> later we can also add programetic behaviour depending on them
20:26:11 <bcoca> like ... chose for windows platform or not ...
20:27:04 <jborean93> anywho, anything else people wanted to talk about?
20:27:17 <briantist> nah, I gotta run anyway
20:27:17 <nitzmahone> nothing here
20:27:35 <bcoca> teh weather is not nice today ...
20:27:39 <briantist> but lmk what comes up on the collection split, even outside of WWG, very interested
20:27:55 <nitzmahone> Ci will be "fun"
20:27:56 <jborean93> will definitely do
20:28:12 <bcoca> briantist: collection split enables many things, for core team ... the ability to concentrate on 'core features' and stop being plugin gatekeepers
20:28:14 <jborean93> yea I'm not looking forward to that but we already have some module tests that promote itself as a DC to test out
20:28:23 <jborean93> At least this way we only need to do that as a once off setup
20:28:44 <jborean93> bcoca: except in this case where we are still the gatekeepers of Windows stuff...
20:28:46 <bcoca> ah, diff split, nvmd
20:28:50 <nitzmahone> Yeah, and having it isolated to the collection that needs it makes everything else suffer less from the extra time to stand up domains
20:29:00 <bcoca> jborean93:  with some exceptions ... ansible.posix also
20:29:23 <jborean93> cool, thanks all for coming and the ideas given
20:29:28 <jborean93> #endmeeting