20:00:01 <jborean93> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Feb  1 20:00:01 2022 UTC.
20:00:01 <zodbot> This meeting is logged and archived in a public location.
20:00:02 <zodbot> The chair is jborean93. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:02 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:07 <briantist> o/
20:00:11 <jborean93> hey
20:00:29 <nitzmahone> o/
20:00:35 <jborean93> #chair nitzmahone
20:00:35 <zodbot> Current chairs: jborean93 nitzmahone
20:00:46 <jborean93> #topic https://github.com/ansible/community/issues/644#issuecomment-1027227209 - Local Pwsh Actions
20:01:27 <jborean93> Just reading through this again to get a clear picture
20:02:21 <briantist> yeah, will give a few mins to read, submitted last minute sorry
20:03:30 <nitzmahone> So it's really still a module, it's just executing on the controller ala the networking modules or other things- it's more like a replacer-style module
20:03:46 <nitzmahone> (since you don't/can't have the Windows exec wrapper)
20:04:09 <jborean93> So I'm not adverse to the idea, I think it would be great to support pwsh outside of Windows, it might even prod up to start actually support it as it's a nice use case
20:04:10 <briantist> hm, I think it still has all the regular wrappers
20:04:13 <nitzmahone> If we had exec subsystems, this would probably be a different one than Windows pwsh/PS5
20:04:52 <jborean93> I just don't think it's really doable at this point in time without many caveats/something I really want in c.w at this point in time
20:05:43 <briantist> it's certainly not full support for everything as written, but the idea is that, if you module is written in a way that it could execute in pwsh/on linux, it will work without needing to do anything else special to it (for example, `win_ping` works fine)
20:05:59 <jborean93> I'm happy to fix `Ansible.Basic` to comment out that code outside of Windows, IIRC there's already a mechanism to do so. But the custom connection/shell plugin most likely will be best in it's own collection for now
20:06:02 <nitzmahone> Yeah, it's likely to be a little fragile whenever we start moving things around, but it's a good use case that we should keep in mind *as* we move things around.
20:06:20 <jborean93> At a start, the exec wrapper will fail as soon as someone requests async or become support
20:06:25 <briantist> obviously many modules will have windows-isms that can't work on linux but that isn't what this is intended to address either
20:06:46 <briantist> yes that's true, I didn't implement async support in this iteration, but that's the kind of thing that could be solved before being accepted
20:07:19 <briantist> the `Ansible.Basic` fix on its own would be very helpful in any case, even if they end up in their own collection
20:07:23 <nitzmahone> It's basically needing to implement a new exec subsystem that Powershell-ish, except there's not a "proper" way to do it right now, so anything you do there will be potentially broken
20:07:45 <nitzmahone> (by abusing things in the action/connection layer)
20:07:57 <jborean93> Unfortunately Windows goes it's own way for async/become. It may be possible to just reutilise what's already there and just take advantage of the generic exec wrapper for sharing/loading utils but nitz's point above still stands
20:09:01 <nitzmahone> (there are other things out there doing similar things, eg, networking modules, IBMz)
20:09:30 <nitzmahone> There was actually someone that implemented a full module subsystem for VAX/VMS
20:10:06 <jborean93> But there's already a compile flag for running on something that's not Windows
20:10:07 <jborean93> https://github.com/ansible/ansible/blob/41db6d8d35900d425df3228406db3fec61ab2269/lib/ansible/module_utils/powershell/Ansible.ModuleUtils.AddType.psm1#L50
20:10:07 <nitzmahone> The IBMz thing lets you do modules in Python or REXX, with module_utils and everything- and it handles all the UTF-8->EBCDIC mess
20:10:37 <jborean93> if #UNIX
20:10:39 <nitzmahone> But they're all extremely fragile
20:11:09 <briantist> hm, I remember seeing that flag, but IIRC it didn't solve the event log thing?
20:11:59 <jborean93> So a PR to Ansible.Basic should do the same thing here https://www.irccloud.com/pastebin/rblfrVvm/
20:12:17 <briantist> ah got it I see what you're saying
20:12:48 <jborean93> I'm happy to accept a PR for that so they don't need their own local copy of all that
20:13:02 <jborean93> probably needs the same thing with Tmpdir to raise a NotImplementedException() at elast
20:13:09 <briantist> cool, that would help a t lot
20:13:41 <jborean93> There might be others but those are the only 2 Windows specific stuff off the top of my head
20:13:52 <nitzmahone> Is that preprocessing and templating the output code, or is it just client-side?
20:14:19 <jborean93> it's processed as part of the .NET compiler
20:14:38 <nitzmahone> OK cool, just wanted to make sure we weren't doing it in the payload builder
20:15:07 <nitzmahone> I don't want to get back in the business of heavily templating module/module_utils code, because it will screw us for some of the caching stuff I want to do
20:15:14 <jborean93> nah, we define them as part of `Add-CSharpType` and .NET processes them accordingly https://github.com/ansible/ansible/blob/41db6d8d35900d425df3228406db3fec61ab2269/lib/ansible/module_utils/powershell/Ansible.ModuleUtils.AddType.psm1#L85-L111
20:15:51 <nitzmahone> noice
20:15:52 <jborean93> and so far they are all just environment specific flags so hopefully won't affect caching
20:16:02 <nitzmahone> nope, it wouldn't
20:16:19 <jborean93> Can't say I've ever used the `WINDOWS` or `UNIX` ones but I added it for just these scenarios if we ever did start using pwsh outside of Windows
20:16:24 <nitzmahone> Just making sure you hadn't added something to deal with that on the controller side that I didn't know about ;)
20:17:03 <briantist> thank goodness for that foresight :)
20:18:01 <jborean93> As for the other plugins for now I think it's best to keep in their own collection. We cannot guarantee that the internals will continue to work though
20:18:25 <briantist> of course, definitely not looking for a guarantee there
20:19:36 <jborean93> #topic open floor
20:19:51 <jborean93> unless you had anything else you wanted to say on the previous sorry
20:20:08 <briantist> in other news, I am excited about the SQL server collection generally,  not much to see there at the moment but the content exists locally
20:20:15 <briantist> nah open floor is fine
20:20:16 <nitzmahone> I don't think I mentioned this last week, but we now have unofficial Win10 and Win11 test target support in ansible-core-ci
20:20:25 <jborean93> Nice to both
20:20:27 <briantist> oh that's interesting
20:20:48 <jborean93> I know nitz was toying with the idea of making cross platform pwsh modules and SQL was one of the main drivers behind that
20:21:24 <nitzmahone> Dunno if you were blessed with a core-ci key, but if so, you can do things like `ansible-test shell --remote windows/11 --remote-provider=azure`, run tests, whatever. If not, it's still possible to add `windows/10` or 11 to a CI matrix now.
20:22:12 <briantist> unfortunately not blessed with such a key
20:22:13 <jborean93> I've let the CI for a.w and c.w languish for a bit. I've found a problem with the `win_reboot` tests which should be now fixed. There's an outstanding problem with a test in `c.w` that sets up a domain and I think I have an hack-ish way to make that a bit more stable. Luckily there were no other major problems
20:22:47 <briantist> I am very interested in the work on that domain promo test, if you wouldn't mind can you @ me on any issues/PRs around that?
20:23:03 <jborean93> like the current test failure?
20:23:10 <briantist> sure, yeah
20:23:27 <briantist> I plan to do some similar things in molecule tests internally for some of our Windows collections/roles/playbooks
20:23:49 <jborean93> I'm essentially just going to put a try/until on a simple `Get-AD*` call like I had on many of my domain creation playbooks before win_reboot was improved to wait for it
20:24:00 <nitzmahone> Word to the wise: don't try to pass a negative timeout to currently-released versions of `win_reboot` ;)
20:24:07 <briantist> so I just want to stay updated if there's issues with it, or anything I can learn
20:24:09 <jborean93> I'm hoping that it's just a bit slow for ADWS to actually finish starting up
20:24:19 <jborean93> but I will definitely ping you
20:24:24 <briantist> thank you!
20:24:41 <jborean93> nitzmahone: only if you have a really slow host though, all the non-2012 ones were quick enough for it to not matter :)
20:24:47 <nitzmahone> heh
20:26:49 <jborean93> On the pypsrp front I think I've adapted the main code to work with the new httpcore. Proxies are turning out to be a lot trickier which has blocked me so far unfortunately
20:26:58 <briantist> sweeeet
20:27:13 <briantist> ah didn't read to the end heh
20:27:14 <jborean93> The hacks I'm relying on to get normal auth working while not public I think it's stable enough to rely on for now
20:27:39 <briantist> oh I saw your PSOpenAD repo, that looks very cool
20:27:54 <jborean93> Thanks, that's been a fun side project I've been working on in my spare time
20:28:06 <jborean93> Finally was stable enough for an MVP
20:29:08 <briantist> lack of AD support is a big blocker for folks moving away from Windows PowerShell, so I'm sure it'll gain some traction
20:30:12 <jborean93> It'll be interesting if it does get used. I tried my best to make thins as simple as I could out of the box but still Windows makes it pretty darn simple for integrated auth compared to Linux
20:30:34 <jborean93> Plus right now it's it very limited, really just the basic `Get-AD*` operations are there
20:30:54 <briantist> reads are a good start
20:31:07 <briantist> lots of stuff out there that is just data massaging to build reports or whatever
20:31:26 <briantist> but yeah, the authentication part is always going to be a challenge
20:31:32 <jborean93> yea, was essentially the easiest low hanging fruit to prove my connection and authentication code actually works :)
20:32:08 <jborean93> I gave up trying to get OpenLDAP and Cyrus-SASL working cross platform, too many caveats, too many outdated packages, too much ambiguity in the docs so I just dropped it
20:32:30 <briantist> right
20:33:28 <jborean93> Any last things to talk about before getting back to our day?
20:33:40 <jborean93> I've got another scorcher + humidty which is going to be fun
20:34:22 <briantist> nothing else from me
20:35:07 <jborean93> cool, let me know if you need anything for the PR to Ansible.Basic but hopefully it's somewhat straightforward
20:35:10 <jborean93> #endmeeting