20:00:42 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:42 <zodbot> Meeting started Tue Apr 21 20:00:42 2020 UTC.
20:00:42 <zodbot> This meeting is logged and archived in a public location.
20:00:42 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:42 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:01:00 <ShachafGoldstein> hi
20:01:06 <nitzmahone> Hey, long time no see!
20:01:19 <nitzmahone> How's things?
20:01:57 <Shachaf92> corona
20:02:00 <Shachaf92> :)
20:02:13 <Shachaf92> you?
20:02:20 <nitzmahone> Heh, yeah, business as usual for the Ansible team, since we're all 100% remote anyway
20:02:47 <nitzmahone> (other than kids being home and no "extracurricular" activities)
20:03:06 <Shachaf92> yeah for me also, though i didn't think i will miss open space office this much
20:03:53 <nitzmahone> I had a private office for most of my career- moving to a cubicle was annoying, and moving to an open office completely destroyed my productivity (and health)
20:03:56 <bcoca> ansible -m kids -a 'state=entertained' all
20:04:04 <nitzmahone> `ERROR`
20:04:25 <bcoca> 'DISTRACTION UNREACHABLE'
20:04:48 <Shachaf92> haha
20:04:50 <nitzmahone> Working from home was such a great change for me- I miss the watercooler talk and stuff, but I definitely don't miss people coming to work sick and making everyone else sick
20:05:04 <nitzmahone> (even long before coronavirus)
20:06:06 <nitzmahone> My kid was thrilled with no school for about a week- the virtual class thing is a poor substitute, but I'm definitely not looking forward to summer w/ no school at all if everything is still locked down
20:07:16 <briantist> Office can definitely be distracting, but I do miss all the food and drinks we have, and I'm really not feeling zoom "happy hours"
20:08:28 <nitzmahone> Heh, the last open office startup I was at had an admin that would bring treats around to our desks... I gained ~20lb in 8mo. At least make me get up and walk over to the kitchen to overindulge myself...
20:08:57 * bcoca misses 'thursday delights' .. good catering in NYC
20:09:12 <briantist> lol snack delivery, wow
20:10:51 <nitzmahone> Yeah... :( I've been cooking a lot more lately since we can't go out to eat, but also overbuying treats, which has put me back on an unhappy weight trend.
20:10:52 <briantist> I like the office cold brew so much so I ordered cases of it in cans since I'm WFH for the foreseeable future. They gave our office a 35% off discount code for the month which is nice
20:11:04 <nitzmahone> wow, that's cool
20:11:20 <nitzmahone> Well, nothing on the agenda today
20:11:23 <nitzmahone> #topic open floor
20:11:30 <briantist> ah same.. not that I had good habits beforehand but at least I walked between subway the home/office
20:12:02 <nitzmahone> Yeah, I definitely miss the daily ~2mi walk the kiddo to school- often my only excuse to get out of the house
20:12:20 <briantist> on topic, I just put in a PR for `win_pssession_configuration`: https://github.com/ansible-collections/community.windows/pull/79
20:12:34 <briantist> got some kinks to work out but it's mostly done
20:12:40 <nitzmahone> noice, we'll take a look
20:13:15 <jborean93> sorry was distracted before
20:13:21 <nitzmahone> #chair jborean93
20:13:21 <zodbot> Current chairs: jborean93 nitzmahone
20:13:35 <briantist> most confusing thing right now is that I'm getting an error on the async timeout deep in `/module_manifest.py", line 301, in _create_powershell_wrapper` but only in shippable
20:13:58 <nitzmahone> briantist: do you have a link to a failing run?
20:14:02 <briantist> that doesn't happen using `ansible-test windows-integration` locally (nor does it happen just using the  module in Ansible normally)
20:14:11 <briantist> https://app.shippable.com/github/ansible-collections/community.windows/runs/135/28/tests
20:14:21 * nitzmahone looks
20:14:40 <nitzmahone> eeenteresting
20:14:53 <nitzmahone> That's definitely a bug, I'm just not sure why you're not hitting it locally
20:15:07 <jborean93> potentially something in the action plugin is just copying an existing setting of the `async` task directive
20:16:11 <jborean93> but does sound like we should also be checking it isn't `None`because it looks like it can be
20:16:17 <briantist> long story short it's somewhat related to the action plugin, maybe it's the way I call execute_module. So the wrapper code is getting `None` and comparing to `0` which sure, seems like it should fail, but I don't understand how that doesn't happen executing outside of shippable
20:16:22 <nitzmahone> Yeah- mostly just surprised it's not failing 100%
20:17:13 <nitzmahone> We don't have a lot of async outside of `normal.py`, so I think Jordan's got the right idea- there's probably something where we're expecting to read the value from the task but the task isn't the one doing the async in this case
20:17:39 <briantist> current workaround I'm trying to set it to `0` all the time, but latest run looks like that failed too (same error, I probably didn't set it right): https://app.shippable.com/github/ansible-collections/community.windows/runs/138/summary/console
20:18:11 <briantist> ok that's a good clue, I'll look over `normal.py` too and see if I can glean anything from that to help workaround
20:18:28 <nitzmahone> (normal's just delegating to the ActionBase for most of that)
20:18:53 <briantist> will follow the breadcrumbs then :)
20:19:14 <nitzmahone> But IIUC you're rolling your own call to the async stuff, so some of the asumptions that code makes about pulling the async attrs from the task itself are probably not valid.
20:19:17 <jborean93> looks like a simple fix in ansible though, just change that line from `if async_timeout > 0:` to just `if async_timeout:`
20:19:47 <nitzmahone> yep, just mostly thinking there might be other cases that aren't handled right either
20:19:57 <nitzmahone> The async stuff has always been a bit of a hack
20:21:10 <nitzmahone> Ideally the executor would treat everything as async, then there'd just be a sync adapter for the cases that aren't, rather than having all the exceptional stuff to make async "work" the way it does today
20:21:30 <nitzmahone> Because really, everything *is* async under the covers, just not at the same level
20:21:49 <nitzmahone> Yo Jon
20:22:05 <briantist> ah I see where I messed up the workaround of setting it to `0`, I can fix that
20:22:29 <jhawkesworth> Hey.  sorry disconnected missed all the scrollback.
20:22:49 <jhawkesworth> tbh brain fried.  sorry I'll catch you next time.  Hope y'all well
20:22:53 * jhawkesworth afk
20:22:56 <nitzmahone> No worries- later!
20:23:31 <briantist> switching gears, I noticed there's some docs for doing unit tests against modules, are there any examples on the Windows side?
20:23:42 <jborean93> we can't do unit tests for windows modules
20:23:44 <jborean93> just Python code
20:23:58 <briantist> I had a handful of functions in this module and found myself wishing I could do that without waiting for integration tests
20:24:09 <nitzmahone> We've both prototyped some things over the years
20:24:13 <jborean93> I had a WIP that added that through Pester but I never went back to clean it up
20:24:14 <nitzmahone> Jordan's got some examples
20:24:25 <jborean93> The biggest issue was where to execute the Pester tests on
20:25:08 <briantist> yeah I was thinking about wrapping all the loose code in a `main()` style function and then just sticking pester tests inside and somehow toggling on whether to run them or the  module, kind of messy.
20:25:43 <briantist> The sanity tests already need pwsh to run the pslint stuff, but I guess doesn't really belong there
20:26:40 <jborean93> yea, the WIP proposed changing powershell modules ot use a main() like function and then expose the rest of the modules functions in a Pester test setup. Unfortunately it ran on the controller so it was limited to pscore on Linux which was 1 big hurdle
20:26:58 <jborean93> running on the Windows host is possible but it adds even more overhead and complexity to get it all running
20:27:22 <nitzmahone> (but is also probably the right thing to do to enable the most useful testing)
20:27:41 <briantist> for unit tests I should think it'd be ok to run on linux for the most part, no?
20:27:51 <nitzmahone> Basically similar to things like code coverage, we'd probably need to add some support to the exec wrapper for things like unit testing.
20:28:14 <jborean93> then doing that makes it even harder to run it manually with debugging if you want to figure out why things are failing
20:28:16 <nitzmahone> Under the covers it's already pretty dynamic, so there'd just need to be a mode that'd smuggle in the right code
20:28:37 <jborean93> unfortunately there isn't an easy answer for all this which is why it hasn't been implemented
20:28:52 <briantist> another option might be to encourage more use of module_utils even for code that isn't really shared between modules, but that complicates things in its own ways
20:29:21 <jborean93> yea you can currently write your own unit style tests for module_utils
20:29:34 <jborean93> but I wouldn't recommend doing that for module specific code
20:31:02 <briantist> right I was thinking of the module_util in that case being more like the container of the functions you'd typically define directly in the module, but that's really changing the purpose of a module_util then..
20:31:37 <jborean93> it also makes it more of a public interface, you can put whatever docs you want but it won't necessarily stop people from using it when it's really a private implementation
20:31:52 <briantist> very true
20:33:43 <nitzmahone> Yeah, the way I was thinking about it a few years back was to basically package the module exactly as it is, but if you're doing unit tests, smuggle in a boilerplate unit test wrapper and change the called execution entrypoint to go through pester and smuggle back the pester output. Then theoretically you can debug the tests normally through ISE or VSCode on the hosts the same way you'd do module dev, so long as you're not
20:33:43 <nitzmahone> needing to debug the wrapper itself
20:35:10 <briantist> ah interesting
20:35:24 <nitzmahone> Would need a couple of hooks in the module generation process to enable that (as we do with code coverage)
20:36:52 <nitzmahone> I haven't played with Pester for awhile- a dynamic wrapper approach could also work with something like xUnit, but would be much harder to debug standalone since there's a lot more "magic" happening
20:37:56 <jborean93> it will be interesting to see if their v5 changes make any of this easier
20:38:09 <briantist> speaking of major version changes, only other thing I have today is this: https://github.com/ansible-collections/community.windows/issues/77
20:38:18 <briantist> just thinking about PowerShellget 3.0 and how to handle it. I haven't had much time to seriously dig into it actually, but wanted to start tracking it.
20:38:41 <jborean93> I haven't looked into it either
20:39:04 <jborean93> my thoughts would be to scale back the existing `_info` modules we have for PSGet and only return a small subset that we know is available in both
20:39:31 <jborean93> IIRC right now it just returns the actual object in a more Ansible like output
20:39:53 <nitzmahone> Heh, we should see if there are any great ideas there for `ansible-galaxy` CLI too ;)
20:40:43 <nitzmahone> Definitely some overlap there
20:41:09 <briantist> Yeah the info ones basically just ansible-ize the output. `win_psmodule_info` is a little different in that it's the fusion of `Get-Module` and `Get-InstalledModule`
20:44:51 <jborean93> but in the end I think we either simplify what we have so it's uniform across both versions, or just state this is returned directly from PSGet
20:45:05 <jborean93> and that v3 is being quite liberal in what it is changing
20:47:18 <nitzmahone> Also probably wait until it hits RC to do anything major, since y'know, things change. :)
20:47:48 <nitzmahone> (and we've never gotten burned by that before, nope)
20:48:02 <briantist> yeah for sure, it's not all decided yet, but the major changes described so far warrant some though. I'm way more worried about the modules that change things though, the info ones are worlds easier to adapt
20:48:24 <jborean93> I would say the non info ones will be broken until someone decides to fix them
20:48:38 <jborean93> without having a stable release or at least a proper rc then there's not much we can do
20:49:07 <jborean93> and based on the cf that is PowerShell package management I doubt v3 will be on a normal WinPS installation
20:50:10 <briantist> yeah agreed and said as much in the issue, it's mainly for brainstorming on path to take. A short term thing to change might just be a check that fails early in the existing modules if it can't load 2.x (if only 3.x is available). Other than that the rest is still up in the air.
20:50:56 <briantist> One of the most interesting changes in 3.0 is that they are dropping package management :)
20:50:58 <jborean93> I personally would just ignore it for now until we know more and can test with a proper release
20:51:30 <jborean93> Who knows the subset of features we implement may work or at least some work so there might not be anything we need to do
20:52:00 <jborean93> the package management providers were a nice idea on paper, just poorly executed and sold
20:52:05 <briantist> makes sense, I'm not planning on doing anything either, just thinkin'
20:52:31 <briantist> yeah agreed, package management could have been cool, just didn't go anywhere
20:53:07 <briantist> kind of like powershell workflows, and the transaction support
20:57:05 * nitzmahone -> next meeting
20:58:51 <jborean93> cool, is there anything else you wish to talk about?
20:59:33 <briantist> 🙊
20:59:54 <briantist> all good from me, thanks everyone
21:00:05 <jborean93> awesome
21:00:09 <jborean93> well have a good one all
21:00:12 <jborean93> #endmeeting