20:01:16 #startmeeting Ansible Windows Working Group 20:01:16 Meeting started Tue Apr 27 20:01:16 2021 UTC. 20:01:16 This meeting is logged and archived in a public location. 20:01:16 The chair is briantist. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:16 The meeting name has been set to 'ansible_windows_working_group' 20:01:23 lol I didn't think that would work 20:03:57 I'm not sure if anyone is actually here, or if this meeting was skipped or whatever.. was not intending to actually run it, but I guess I'll stick around for a few just in case and then end it unless an actual chair shows up 20:06:00 nothing on the agenda https://github.com/ansible/community/issues/581 20:06:28 #topic Open Floor 20:09:15 sorry time slipped past me 20:09:28 #chair jborean93 20:09:28 Current chairs: briantist jborean93 20:09:37 thanks for kicking it off though briantist 20:09:39 how are you? 20:09:40 that's ok, usually happens to me too 20:09:58 hehe I honestly didn't think I could, was kind of doing it jokingly 😅 20:10:24 I'm alright, been hectic hence why I missed a few 20:10:30 yourself? 20:10:43 not too bad, have too many things I need to comlpete and not enough time 20:10:55 I know that tune... 20:11:05 I've resigned myself to the fact I need to touch win_updates which is not my favourite thing in the world 20:11:13 😭😭😭 20:11:17 what's going on with it? 20:11:36 a few issues have popped up that I've been somewhat ignoring 20:12:10 I'm also in the middle of trying to make win_reboot a bit more stable with psrp and ssh 20:12:33 Currently going through the rounds of testing it out as the issues I'm trying to solve are quite sporatic in nature 20:12:52 we are using `win_updates` but it's being phased out for a non-ansible update system, and unfortunately we don't monitor the ansible one well, so I'm not even sure if it's misbehaving for us 20:13:21 oh does `win_reboot` have issues with `psrp`? what happens? 20:14:12 I've encountered a few problems especially when it comes to a reboot with a domain join. But I'm unsure if it's psrp specific or if it also happens with WinRM 20:14:47 does it look vaguely like a DNS issue by any chance? 20:14:51 It's just unfortunate I missed a few exceptions in exec_command so some request timeout (Connect/Read Timeout) are raised and not converted to an AnsibleConnectionError that win_reboot sometimes catches 20:15:44 #chair nitzmahone 20:15:45 Current chairs: briantist jborean93 nitzmahone 20:15:49 hey 20:15:55 howdy 20:16:22 sorry, IRCCloud hassles 20:16:40 Nothing exciting from me 20:18:19 jborean93: the reason I asked about DNS, is I saw a strange issue last year during a domain join process on EC2 instances, where a `Restart-Computer` call would fail with a very strange looking DNS resolution error, somewhere deep in the stack, but I couldn't actually show DNS resolution issues with any other tool, and `shutdown -r -t 0` worked. 20:18:22 here's the draft PR I thought I opened https://github.com/ansible-collections/ansible.windows/pull/214 20:18:51 was it a ps stack or python stack? 20:19:00 but we could only surface that problem when assigning DNS servers via DHCP. Super strange (nothing to do with ansible btw) 20:19:09 ps 20:19:26 we also do `-t 2` (or maybe 5) to give it time to return the output before it closes the connection 20:19:46 yea the errors are more Python requests based errors that I sometimes saw slip through 20:20:37 it was the userdata script run by AWS on startup, we'd been using the same script for a long time. But we were using `Restart-Computer` cmdlet, and it always worked. Just started failing when we switched to DHCP DNS assignment instead of static. Never did find an explanation as a reorg happened and the DHCP/DNS project was suspended 20:20:48 got it ok 20:21:23 weird maybe it still tries to resolve the local hostname even when `-ComputerName` isn't specified 20:22:11 in any case I need to try these changes out a bit more before merging. Once that is done it's onto win_updates which will hopfully utilise the new plugin_util instead of calling win_reboot directly 20:22:12 Just out of curiosity, were you renaming the host at the same time with the domain-join? I've seen more problems from that case than when the hostname stays the same 20:22:13 yeah that's the weird thing though, running other commands (`nslookup`, .net object DNS resolution, cmdlets, etc.`) run before that call all resolve the computer name, domain name, `localhost` successfully. 20:22:52 yeah definitely it was being renamed, but that part has always worked flawlessly (still does) 20:23:28 anyway that's all ancient history for me at this point 20:23:36 jborean93: will check out that PR 20:24:09 +1 on that PR as well (conceptually, anyway)- the subclassing made more sense when everything was in core, but scary when they're split 20:24:38 yea nothing has broken but I don't want to risk it 20:25:52 "Removed ``shutdown_timeout`` and ``shutdown_timeout_sec`` which has not done anything since Ansible 2.5" 20:26:20 they are still listed in valid args, is that to not breka backwards compat? 20:26:43 they aren't documented 20:26:49 and haven't done anything since 2.5 20:26:52 ahhh ok 20:27:07 it also had a warning message whenever they were used, I think it's about time to remove them 20:27:37 ok yeah I was just thinking if they were official they should be breaking changes/major version, but if they were never documented seems fine to remove by now 20:27:40 while we never said in the message when it was going to be removed I would hope that nobody has it set anymore 20:28:28 👍 20:28:29 if they do then really I prefer them to just remove the options as anybody who uses this collection will be on at least 2.9 20:31:27 well, nothing else from me 20:34:04 cool, I've got nothing else to add as well 20:35:37 sounds good, thanks, sorry for stealing a chair haha ;) 20:35:42 #endmeeting