20:00:42 #startmeeting Ansible Windows Working Group 20:00:42 Meeting started Tue Apr 21 20:00:42 2020 UTC. 20:00:42 This meeting is logged and archived in a public location. 20:00:42 The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:42 The meeting name has been set to 'ansible_windows_working_group' 20:01:00 hi 20:01:06 Hey, long time no see! 20:01:19 How's things? 20:01:57 corona 20:02:00 :) 20:02:13 you? 20:02:20 Heh, yeah, business as usual for the Ansible team, since we're all 100% remote anyway 20:02:47 (other than kids being home and no "extracurricular" activities) 20:03:06 yeah for me also, though i didn't think i will miss open space office this much 20:03:53 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 ansible -m kids -a 'state=entertained' all 20:04:04 `ERROR` 20:04:25 'DISTRACTION UNREACHABLE' 20:04:48 haha 20:04:50 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 (even long before coronavirus) 20:06:06 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 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 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 lol snack delivery, wow 20:10:51 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 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 wow, that's cool 20:11:20 Well, nothing on the agenda today 20:11:23 #topic open floor 20:11:30 ah same.. not that I had good habits beforehand but at least I walked between subway the home/office 20:12:02 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 on topic, I just put in a PR for `win_pssession_configuration`: https://github.com/ansible-collections/community.windows/pull/79 20:12:34 got some kinks to work out but it's mostly done 20:12:40 noice, we'll take a look 20:13:15 sorry was distracted before 20:13:21 #chair jborean93 20:13:21 Current chairs: jborean93 nitzmahone 20:13:35 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 briantist: do you have a link to a failing run? 20:14:02 that doesn't happen using `ansible-test windows-integration` locally (nor does it happen just using the module in Ansible normally) 20:14:11 https://app.shippable.com/github/ansible-collections/community.windows/runs/135/28/tests 20:14:21 * nitzmahone looks 20:14:40 eeenteresting 20:14:53 That's definitely a bug, I'm just not sure why you're not hitting it locally 20:15:07 potentially something in the action plugin is just copying an existing setting of the `async` task directive 20:16:11 but does sound like we should also be checking it isn't `None`because it looks like it can be 20:16:17 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 Yeah- mostly just surprised it's not failing 100% 20:17:13 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 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 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 (normal's just delegating to the ActionBase for most of that) 20:18:53 will follow the breadcrumbs then :) 20:19:14 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 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 yep, just mostly thinking there might be other cases that aren't handled right either 20:19:57 The async stuff has always been a bit of a hack 20:21:10 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 Because really, everything *is* async under the covers, just not at the same level 20:21:49 Yo Jon 20:22:05 ah I see where I messed up the workaround of setting it to `0`, I can fix that 20:22:29 Hey. sorry disconnected missed all the scrollback. 20:22:49 tbh brain fried. sorry I'll catch you next time. Hope y'all well 20:22:53 * jhawkesworth afk 20:22:56 No worries- later! 20:23:31 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 we can't do unit tests for windows modules 20:23:44 just Python code 20:23:58 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 We've both prototyped some things over the years 20:24:13 I had a WIP that added that through Pester but I never went back to clean it up 20:24:14 Jordan's got some examples 20:24:25 The biggest issue was where to execute the Pester tests on 20:25:08 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 The sanity tests already need pwsh to run the pslint stuff, but I guess doesn't really belong there 20:26:40 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 running on the Windows host is possible but it adds even more overhead and complexity to get it all running 20:27:22 (but is also probably the right thing to do to enable the most useful testing) 20:27:41 for unit tests I should think it'd be ok to run on linux for the most part, no? 20:27:51 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 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 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 unfortunately there isn't an easy answer for all this which is why it hasn't been implemented 20:28:52 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 yea you can currently write your own unit style tests for module_utils 20:29:34 but I wouldn't recommend doing that for module specific code 20:31:02 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 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 very true 20:33:43 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 needing to debug the wrapper itself 20:35:10 ah interesting 20:35:24 Would need a couple of hooks in the module generation process to enable that (as we do with code coverage) 20:36:52 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 it will be interesting to see if their v5 changes make any of this easier 20:38:09 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 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 I haven't looked into it either 20:39:04 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 IIRC right now it just returns the actual object in a more Ansible like output 20:39:53 Heh, we should see if there are any great ideas there for `ansible-galaxy` CLI too ;) 20:40:43 Definitely some overlap there 20:41:09 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 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 and that v3 is being quite liberal in what it is changing 20:47:18 Also probably wait until it hits RC to do anything major, since y'know, things change. :) 20:47:48 (and we've never gotten burned by that before, nope) 20:48:02 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 I would say the non info ones will be broken until someone decides to fix them 20:48:38 without having a stable release or at least a proper rc then there's not much we can do 20:49:07 and based on the cf that is PowerShell package management I doubt v3 will be on a normal WinPS installation 20:50:10 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 One of the most interesting changes in 3.0 is that they are dropping package management :) 20:50:58 I personally would just ignore it for now until we know more and can test with a proper release 20:51:30 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 the package management providers were a nice idea on paper, just poorly executed and sold 20:52:05 makes sense, I'm not planning on doing anything either, just thinkin' 20:52:31 yeah agreed, package management could have been cool, just didn't go anywhere 20:53:07 kind of like powershell workflows, and the transaction support 20:57:05 * nitzmahone -> next meeting 20:58:51 cool, is there anything else you wish to talk about? 20:59:33 🙊 20:59:54 all good from me, thanks everyone 21:00:05 awesome 21:00:09 well have a good one all 21:00:12 #endmeeting