20:00:31 <jborean93> #startmeeting Ansible Windows Working Group
20:00:31 <zodbot> Meeting started Tue Sep 22 20:00:31 2020 UTC.
20:00:31 <zodbot> This meeting is logged and archived in a public location.
20:00:31 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:31 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:37 <jhawkesworth> hey
20:00:44 <jborean93> hey
20:00:51 <briantist> 🌊hey folks
20:01:06 <jborean93> how is everyone
20:02:54 <jhawkesworth> good thanks, how about you?
20:03:03 <briantist> doing ok, meetings back to back today but otherwise good
20:03:37 <jborean93> not too bad, starting to get hot here, was quite humid yesterday
20:05:02 <jborean93> #topic open floor
20:05:12 <jborean93> nothing on the agenda, anything you wish to discuss
20:05:45 <briantist> yeah I have some questions around possibly arcane areas, want to see what others have done/tried
20:06:10 <jhawkesworth> fire away I don't have anything to ask this time.
20:06:37 <jborean93> go ahead
20:06:41 <briantist> here's the background: someone at my place is trying to powershell on the controller, so using `pwsh`, but the PowerShell-based module support in Ansible is kinda/sorta hardcoded to Windows only
20:07:02 <briantist> so they're suing `shell:` calls with `executable: pwsh` and I'm like "bleh I hate this"
20:07:35 <briantist> wondering what's been tried before if anything, even just experimenting, with running powershell modules against linux/the controller
20:07:55 <briantist> is there a possible avenue with changing the "shell" plugin?
20:08:00 <jborean93> I have a comment on GitHub that goes across a few of those scenarios
20:08:09 <briantist> ohhh sweet, can you link me to that?
20:08:10 <jborean93> it's all hackish unfortunately
20:08:18 <jborean93> yep, trying to find it now
20:08:45 <briantist> perfect thanks! I expected hackish at this point without their being direct project support
20:09:14 <jborean93> https://github.com/ansible/ansible/issues/48881#issuecomment-440481672
20:09:48 <briantist> but that might be doable as far as something we support internally, I'd just rather do something that lends itself well to being supported in the future, whenever it's possible to do so. Right now, I really don't want to encourage using `shell:` tasks
20:10:33 <briantist> this is  great, thanks Jordan I'll look over this
20:10:39 * nitzmahone mumbles something about pluggable exec subsystems
20:10:40 <jhawkesworth> yeah I think tbh the 'using shell'ness is more of an issue than what executable is use when you do use shell
20:10:55 <jborean93> yea creating custom .ps1 modules works for powershell core on Linux, you just can't use the module_utils we have today
20:10:58 <jhawkesworth> in other words don't fight the grain and use modules on the controller
20:10:59 <briantist> yes, agreed
20:11:17 <jborean93> modules can be in any language you want, even a binary executable
20:11:38 <briantist> right, interesting. So it's just a  module_util issue?
20:12:24 <jborean93> there are a few problems. 1. we haven't tested the powershell module utils with core and there's a good chance they won't work due to the .NET and platform differences
20:12:24 <nitzmahone> not just
20:12:42 <jborean93> 2. we haven't plumbed in the logic to handle module_utils for PowerShell outside of Windows
20:13:06 <jborean93> Right now it's pretty much hardcoded to use the PowerShell exec system which is designed for Windows PowerShell and Windows itself
20:13:09 <nitzmahone> Yeah, the exec wrapper also has a lot of Windows-isms baked into it
20:13:20 <briantist> got it ok. for these specific modules, the only util we'd be likely to use is the AnsibleModule one, but that cold be worked around since it's  not even technically a requirement.
20:13:25 <briantist> ok yeah that's a lot of good info
20:13:38 <jborean93> the thing that nitzmahone is alluding to (exec subsystems) is something we've been wanting to implement for a while to make this easier to implement
20:13:53 <nitzmahone> We've both done some prototyping around making it work for PS Core on Windows- that's not too bad, but Linux would likely need a pretty different exec wrapper
20:14:06 <jhawkesworth> unless there's load of effort gone into the pwsh code  I would really encourage using modules as you get idempotency checks and boat loads of battle-tested implementations in the box, but I'm sure you know this already.
20:14:10 <nitzmahone> s/Linux/NotWindows/
20:14:59 <nitzmahone> You could also copy/paste some of the existing module_utils bits (eg arg validation) into your modules temporarily, then refactor that out if/when we have proper first class support for it later
20:15:07 <jborean93> so yea you loose out on the AnsibleModule stuff which is sad, but you still have the ability to run PowerShell code and make it idempotent
20:15:52 <nitzmahone> But there's a lot of boilerplate services provided by the wrapper (eg dynamic compilation of C# stuff) that you'd have to tease apart and get in there too
20:16:02 <jhawkesworth> yep, convert the pwsh into custom modules and you can switch it out later if you need is also an option
20:17:08 <nitzmahone> But yeah, using it as a script module via shebang worked seamlessly when I tried it
20:17:44 * nitzmahone tries to remember if the hardcoded POSIX subsystem is still excluding *.ps1- I think it's not anymore
20:19:47 <briantist> got it yeah, I would definitely like to stick to modules for all the reasons. I definitely wouldn't mind pre-compiling the C# module util or otherwise figuring out how to host it separately to get the wrapper benefits, if needed. Lots of options there.
20:19:58 <briantist> this info is very helpful
20:21:16 <nitzmahone> Precompiling would only work if it were already in place, or if you did the modules as exe's (at which point they'd be C# modules, not PS)
20:21:46 <nitzmahone> (eg you'd have to pre-stage the compiled assemblies, since the script/binary module subsystems require single-file payloads today)
20:23:34 <nitzmahone> On the plus side, you'd still be able to do `become` with `sudo` since that's implemented on a different layer for POSIX
20:29:04 <jborean93> cool, do you have anymore questions around that briantist?
20:29:06 <briantist> Pre-staging would be fine because the intention is to run from the controller. The basic thing happening here is that these are tasks handling SQL server stuff. The team doesn't want to rely on running stuff on Windows servers because 1) some workloads may go to RDS 2) not having to manage dependencies on SQL servers if some of the workflows need to run outside of it (against RDS for example)
20:29:44 <briantist> sorry for the delay, got pulled into another meeting
20:29:50 <jborean93> no worries
20:30:17 <jborean93> I know SQL was a driver to trying to unify the exec subsystem so we could have 1 set of modules that worked on Windows and Linux
20:30:27 <nitzmahone> yaasss
20:30:56 * nitzmahone keeps waiting for that one to turn into a fire drill
20:33:22 <briantist> that's interesting stuff, the exec subsytem changes seem worthwhile, but Difficult ™️
20:33:43 <jborean93> one day
20:33:47 <jborean93> the list keeps on growing
20:34:50 <nitzmahone> Heh, yes and no- the exec subsystem abstraction itself shouldn't be too bad, but there are several other architectural blockers to doing it efficiently that we should correct first, and once those are out of the way, it might look a little different.
20:37:46 <briantist> awesome thanks, this is great info
20:41:50 <briantist> also, if those architectural blockers or the abstraction itself gets prioritized again and there's room for outside contributors, let me know. Can't guarantee anything but if it's possible I'd like to help it along
20:42:51 <jhawkesworth> I gotta go, catch you next time folks
20:42:55 * jhawkesworth afk
20:43:09 <jborean93> cya, have a good one
20:43:12 <jborean93> will do briantist
20:45:32 <briantist> thanks, definitely enough to chew on here so nothing else from me
20:45:50 <jborean93> cool
20:46:00 <jborean93> if that's everything let's bring this to a close
20:46:34 <jborean93> #endmeeting