20:00:01 #startmeeting Ansible Windows Working Group 20:00:01 Meeting started Tue Feb 8 20:00:01 2022 UTC. 20:00:01 This meeting is logged and archived in a public location. 20:00:01 The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:01 The meeting name has been set to 'ansible_windows_working_group' 20:00:04 bah 20:00:09 #chair jborean93 20:00:09 Current chairs: jborean93 nitzmahone 20:00:13 #agenda https://github.com/ansible/community/issues/644 20:00:36 Looks like nothing new for today, so 20:00:38 #topic open floor 20:00:38 yo 20:00:41 hey hey 20:01:11 We'll wait until 5 after for any topics 20:01:13 I've got nothing interesting to share. I believe I've stabilised the tests in a.w and c.w which is nice 20:01:18 woot 20:01:51 Oh, and in case briantist is around, mattclay has a fix for the validate-modules when only PS modules are present issue merged to devel 20:02:01 hello! 20:02:12 (though apparently there's something weird with the backport for 2.12) 20:02:13 yeah I saw that fix, happy to see it (and the backport!) 20:02:16 oh nooo 20:02:22 We'll get it sorted 20:02:50 Just relying on the implicit collection loader startup from pluginloader wasn't good enough since it needs to customize the collection path 20:03:04 (was the gist, IIRC) 20:03:28 the mssql collection is coming along, currently testing with the pwsh_runner plugin directly in the linux runners, against a sqlserver container 20:03:34 nice 20:03:47 I have some ideas for adding in windows tests too, with the windows runners + WSL 20:04:06 we can't run WSL on server though, and it takes a while to install + reboot on client 20:04:22 So there's a significant cost to adding WSL testing, though it is possible 20:04:47 it works in GitHub runners, and there's a nice action to configure it; my tests with debian WSL on 2022 continue to be crashing when runing ansible command though, have not figured out why yet 20:05:12 https://github.com/briantist/gha-junk/actions/runs/1810147132 20:05:25 https://github.com/briantist/gha-junk/blob/main/.github/workflows/wsl.yml 20:05:29 Yeah, I thought nobody had solved the WSL-on-2022 problem enough to get it functional yet 20:05:40 (and MS was like "go away, not supported") 20:05:49 oh? 20:06:03 Are you doing WSL1 or WSL2? 20:06:06 oops, correct workflow link: https://github.com/briantist/gha-junk/blob/try/.github/workflows/wsl.yml 20:06:19 WSL1 is th eonly one supported on server as far as I know 20:06:21 (I think WSL1 works, but WSL2 is nogo) 20:06:23 aha 20:06:40 and these are VMs without VinV anyway so WSL2 could not work 20:06:41 but yeah, maybe good enough 20:07:06 let's just hope you don't need a reboot :) 20:07:09 Yeah, I put together a gist for how to enable WSL2 on our Win10/Win11 ansible-test VMs 20:07:15 so far seems good enough, except 2022+debian / other Windows or other distro is ok, slow to start of course, 20:07:29 But it takes ~5min to get the VM up, bits installed, and rebooted 20:07:37 GitHub started pre-installing the WSL feature in 2019 runners, so that a rbeoot is not necessary 20:07:53 still have to set up a distro, but no reboot needed 20:08:06 nice- our devtools group needs WSL2 for some testing, so I just wanted to make sure it was possible 20:08:08 That's nice, I remember some crazy setup in the Appveyor days to get it running and it was not fun 20:08:19 and totally unsupported (probably still is) 20:08:33 this guy did great work to make it a lot easier: https://github.com/Vampire/setup-wsl 20:08:34 But hey, it's CI, so long as it works... 20:10:15 Our AZP VMs have nested virt enabled, so WSL2 works fine- just requires either a pre-customized image (which we try to avoid) or passing a custom startup script blob (which was what my test did) 20:10:16 I am wondering if the issues with debian/2022 are going to rear their head with other combos when trying to run stuff more intensive... the runners only have 7 GB of RAM. WSL1 is much lighter on RAM than WSL2 though... so we'll see 20:10:39 that's cool! definitely a lot more flexibility using AZP directly 20:12:10 Passing this script blob to ansible-core-ci on a stock `windows/10` or `windows/11` VM lights it up: https://gist.github.com/nitzmahone/714a6fd9ceea1e08b21b0cdbbbb7090a 20:12:45 > Set-StrictMode -Version 2.0 20:12:45 boo-urns :) 20:12:47 (it replaces the normal bootstrap config we use for WinRM and still calls that one) 20:12:53 :P 20:13:08 lol boo-urns 20:13:40 nice use of `Register-ScheduledJob` 20:14:02 Yeah, that was a PITA, but at least I can rely on those cmdlets being available now :D 20:15:34 I was also bummed we had to roll a new credential, but the Azure agent runs as SYSTEM, which broke a bunch of stuff 20:16:07 that script is very much not production-ready, but just wanted to ensure it was possible 20:16:09 heh, same thing in my GHA workflow 20:16:16 well, not same, doesn't run as system 20:17:34 but don't have the admin password and need creds from wsl to use over psrp 20:17:36 https://github.com/briantist/gha-junk/blob/try/.github/workflows/wsl.yml#L33-L37 20:17:47 Heh, I was recently revisiting my foreign-arch GHA-runner on Windows/arm64- whee 20:18:18 once that stdin/stdout pypsrp stuff is ready and in ansible, I won't need that anymore I reckon 😅 20:18:25 Can't you just force-reset the existing user's password? 20:18:33 haha maybe?? 20:18:46 Meh, at least this way you know exactly what you have... 20:18:57 seems easier to just add a new one, no idea if resetting would mess up the agent runner app 20:19:00 I've done that before for remote-debug in GHA runners 20:19:03 yeah 20:19:19 remote debug in GHA runners? tell me more 👀 20:19:30 IIRC the agent runner isn't `Administrator`, they create their own user, but I could be remembering wrong 20:19:50 (I run mine as a `runner` user I create) 20:20:13 Oh, there are various tricks for getting into them with ssh and RDP reflectors 20:20:53 Trying to debug problems by iteratively running changes is for the birds 20:20:58 that would really help me get to the bottom of this debian/2022 thing... 20:21:31 I should just stop burning hours on that and use ubuntu, but Debian seems to get set up like a full minute quicker, so it would be nice to use.. 20:22:25 Have you use ngrok before? 20:22:35 nope 20:22:45 googling... 20:23:15 is there website down or is that some problem with my connection? 20:23:18 their* 20:23:20 Take a look at it- some people have wrapped it up in actions for interactive debug on Linux hosts, works great... I borrowed similar techniques to get it working on Windows awhile back, but dunno if it still does: https://github.com/nitzmahone/debug-via-ssh 20:23:39 (ngrok.com is working for me from here) 20:23:55 slow but also works for me 20:24:18 cool, thanks! 20:24:19 Basically you have your workflow install/configure an ngrok tunnel 20:24:45 It's "frowned upon", but so long as you're not using it for mining or something, they should leave you alone 20:25:04 (and sometimes it's the only way to figure out what wacky shiz they've done) 20:25:43 then you have your workflow just block and dump the ngrok config, where you can RDP/SSH/whatever to the worker through the reflector 20:26:02 It's a lot harder than it was for Appveyor, but still possible 20:26:10 definitely going to take a look at that 20:26:26 It's a game changer if you've been relying on iterative pushes to diagnose stuff :D 20:26:58 Blows my mind that there's no officially-supported mechanism for this kind of debug 20:27:06 (but maybe a licensing thing or something, who knows) 20:28:08 Welp, if nothing else, we'll wrap it up for this week! 20:28:50 I'm all good 20:29:08 til next week then, thanks all! 20:29:11 #endmeeting