19:59:59 <nitzmahone> #startmeeting Ansible Windows Working Group
19:59:59 <zodbot> Meeting started Tue Oct 20 19:59:59 2020 UTC.
19:59:59 <zodbot> This meeting is logged and archived in a public location.
19:59:59 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:59 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:02 <nitzmahone> bah
20:00:08 <nitzmahone> #chair jborean93
20:00:08 <zodbot> Current chairs: jborean93 nitzmahone
20:00:26 <jborean93> yo
20:00:32 <briantist> 👋
20:00:35 <nitzmahone> Jordan's running the main core meeting today, so might be a bit doubled up
20:02:37 <nitzmahone> Hey Jon and briantist!
20:02:52 <jhawkesworth> Hey
20:03:16 <nitzmahone> #info nothing new on the agenda for today, so ...
20:03:19 <nitzmahone> #topic open floor
20:03:39 <briantist> so in a previous meeting about a month or so ago, I mentioned a coworker trying to write SQL powershell  modules that run on the controller in `pwsh`. Got some great advice from all of you, he went and started to write `WANT_JSON` modules, but it was a bit rough, especially with lots of unexpected output causing failures
20:04:22 <briantist> We had a company hackathon ~2 weeks ago and I set out to get "standard" powershell modules running on the controller in `pwsh` with the goal of 1) no modifications to the module 2) no modification of core ansible code (plugins only)
20:05:14 <briantist> I was able to get this going, but creating two new plugins: a shell plugin (cloned and modified `powershell` into `pwsh`) and a connection plugin (cloned and modified `local` into `pwsh_local`)
20:05:42 <briantist> Only really tested with `win_ping`, and I expect other very windows-specific stuff to fail, but it's a nice milestone I think
20:06:06 <briantist> Should let my coworker write their SQL modules so they execute either in `pwsh` on controller, or remotely on a Windows host, I think
20:06:18 <briantist> Very few modifications needed to the cloned plugins
20:06:38 <jhawkesworth> Nice one.
20:06:47 <nitzmahone> Yeah, ideally the modules themselves should work across platforms with little-to-no hackery, but the module_utils and wrapper is where the hard part is
20:07:10 <briantist> The biggest hacky part was getting Ansible.Basic to work on non-Windows. It compiles successfully (thanks everyone for the effort in actually making sure it compiles), but there's some code like the logging that won't execute on non-Win platform
20:07:27 <nitzmahone> You can't rely on that behavior continuing, either
20:07:51 <briantist> Sure I know. For the logging function, I just no-opped the function. Jordan pointed out that there's another part with temp paths that wouldn't work on non-Win
20:08:09 <briantist> but the hacky part is really how I got the modified Ansible.Basic into the payload
20:08:17 <briantist> because that code is in the executor and not pluggable
20:08:33 <nitzmahone> Basically if you're going to try this before the infra to support it exists, you'll have to clone the entire sequence all the way back to the action/connection/shell plugins and even then, you'll probably be fighting changes, esp once we start doing exec subsystem plugins
20:09:04 <briantist> so in the connection plugin I took the already created payload and overrode the wrapper to use the local copy. It otherwise would've worked without that.
20:09:23 <nitzmahone> I'm saying you can't rely on the "shape" of what's in the executor remaining workable either, you basically have to clone it, and it'll be brittle.
20:09:24 <briantist> nitzmahone: for sure I know this is not supported :)  pluggable exec subsystem would have made some of this easier tbh
20:09:54 <nitzmahone> Well, it'll be brittle one way or another, but less likely to break if you embed it
20:10:55 <briantist> the goal for this was that it provides a somewhat possible path for my colleague to write the modules he wants, and for them to probably/sorta/kinda execute the way he wants, but if it breaks at some point, there's always the fallback of executing them on a remote windows host just as the executor of the module, without having to rewrite the module
20:11:31 <briantist> surely not intended to be something I expect should be emulated [hackathon yolo]
20:12:04 <nitzmahone> The exec subsystem is like 90% implemented under the action, so if you back it out that far, you can embed all of that in a collection and make it work pretty seamlessly
20:12:57 <briantist> I actually did embed this in a collection! By impelmented under the action, do you mean in the action base class?
20:13:02 <briantist> or maybe normal.py or something?
20:13:10 <nitzmahone> The biggest problem at that point is the plugin resolution being tied to properties on the shell/connection, but you've already got that knocked as well. The "real" exec subsystem plugins will have to move a bunch of those things around so they're properly delegated to the new plugin stuff
20:13:14 <jhawkesworth> That sounds like a good goal if you get the chance to hack on it some more
20:14:05 <briantist> I am super excited about pluggable exec subsystem, it sounds like it would only make this kind of thing easier
20:14:06 <nitzmahone> briantist: yeah, like basically 90% of Ansible's concept of modules is implemented under the base action, so with a custom action and collection action redirection, you can get most of the way to custom module exec subsystems today via collections
20:14:33 <nitzmahone> (so use collection action redirection to force it to use your custom action instead of normal.py)
20:14:53 <briantist> action redirection might be the missing link.. I saw the stuff in the action but couldn't figure out how to override that properly without making an action plugin for every single module
20:15:03 <briantist> got a link handy?
20:15:20 <nitzmahone> You make a runtime.yml `action` entry for each module in the collection and redirect it to your custom action.
20:16:06 <briantist> ah ok, but I can't use that to redirect modules in other collections/builtins right?
20:16:27 <nitzmahone> Not outbound, but other collections can do the same thing if they depend on your action
20:16:34 <briantist> (not that that's all that important for my real goal, but I thought it was cool I could attempt to run any module this way the way I'm currently doing it)
20:16:58 <nitzmahone> You can't hijack a name from another collection, but you can cross collections with the redirect *targets*
20:17:24 <briantist> got it, ok, that might have some use as well then, going to keep that in mind
20:17:46 <briantist> is there anywhere I can follow along on the exec subsystem project/progress?
20:18:38 <nitzmahone> Heh, it's nothing beyond a pipedream in my head right now; we're working on some of the architectural changes that are blocking us from doing it "right" currently...
20:19:07 <briantist> ok got it
20:19:45 <nitzmahone> If all those things work out, the plugin will look very different than it would if we implemented it today
20:20:01 <nitzmahone> (but be orders of magnitude more performant :D)
20:20:25 <briantist> one of the things I noticed that makes the win/powershell stuff difficult is that right now all over the codebase, `WINDOWS == POWERSHELL`, and it's a little difficult to separate that out into the platform (win or other) and language
20:20:35 <briantist> ^ maybe not striclty related to the exec subsystem pluggability though
20:20:56 * jhawkesworth has to drop, catch ya next time
20:21:05 <nitzmahone> cya Jon!
20:22:21 <nitzmahone> Yeah, that's definitely one of the issues that I hope to solve properly with the exec plugins, but the structure of the things underneath may or may not initially lend themselves to what you're trying to do much better, other than providing a tighter set of stuff to copy and hack on :)
20:23:01 <nitzmahone> It potentially could end up that way though, but transparent support for PS-on-Linux has never been a real goal IMO
20:23:16 <nitzmahone> The way we'd talked about doing SQL Server modules was C#
20:25:09 <nitzmahone> But even with the exec subsystem thing, I'm guessing the initial versions will mostly be "lift and shift" vs a completely rewritten rethought class hierarchy that'd allow for reuse/extension of various internal bits. I'd love to do it that way, but at least for v1, time will probably be a factor.
20:26:21 <nitzmahone> We definitely want transparent/reusable support for PS Core/pwsh/PS3-5 on Windows though, at least as much as is reasonable
20:26:35 <briantist> nice, all of that sounds good
20:26:48 <nitzmahone> Jordan's made great strides in that area
20:29:41 <nitzmahone> If nothing else exciting for today, closing in 2...
20:30:23 <briantist> 👍
20:30:31 <jborean93> lol and I just finished the core meeting
20:30:36 <jborean93> I've got nothing to add
20:32:03 <nitzmahone> Cool, thanks for the discussion- excited (/scared ;) ) to see what comes of the SQL stuff in the future!
20:32:07 <nitzmahone> #endmeeting