20:01:52 <nitzmahone> #startmeeting ansible windows working group
20:01:52 <zodbot> Meeting started Tue Aug 28 20:01:52 2018 UTC.
20:01:52 <zodbot> This meeting is logged and archived in a public location.
20:01:52 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:52 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:02:04 <dag> imjoseangel: we wait for the meeting to start ;-)
20:02:11 <imjoseangel> Thanks!
20:02:16 <nitzmahone> #chair dag jborean93 jhawkesworth_
20:02:16 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitzmahone
20:02:53 <dag> imjoseangel: we have an agenda at https://github.com/ansible/community/issues/294 but you can add questions at the end of the meeting too
20:03:11 <imjoseangel> Cool! Good to know :P
20:03:16 <dag> or right away if the chairman allows it :)
20:04:21 <imjoseangel> :)
20:04:54 <nitzmahone> #topic https://github.com/ansible/community/issues/294#issuecomment-416550808
20:05:00 <nitzmahone> (modules ready to merge)
20:05:11 <nitzmahone> IIRC we're still waiting for tests on win_wait_for_process
20:05:50 <dag> nitzmahone: should not be hard to add ourselves using async
20:07:02 <nitzmahone> Yeah, I guess- IIRC I had to remove the watchdog_pid stuff from the initial async result, which would make it a little harder
20:07:03 <dag> if that's deemed acceptable
20:07:04 * nitzmahone looks
20:07:53 <nitzmahone> Oh, looks like I did leave it in
20:08:07 <nitzmahone> Oh, I remember the issue there
20:08:57 <nitzmahone> Windows reuses PIDs pretty aggressively, so checking for the presence of a PID in the test is tricky. The async tests originally used that to determine that the watchdog had exited, but I had to remove those tests because of the PID reuse
20:09:29 <bcoca> do you have a window instance id?
20:09:42 <bcoca> i remember those were the 'safe' way to find your windows proc
20:09:47 <dag> if we do this for testing if a PID disappears, I think it would be ok (if we are certain the PID was created and still running)
20:09:56 <dag> which we are
20:10:01 <nitzmahone> @bcoca nope
20:10:40 * bcoca goes back to hole of ancient and out of date windows kb
20:10:49 <nitzmahone> @dag it's a race though; if the PID gets reused between polls, the test will fail falsely
20:11:25 <nitzmahone> (eg, poll: still running, watchdog exits, new process starts and reuses PID, poll: still running -> forever/timeout)
20:11:36 <dag> nitzmahone: but if we async a process that's run for 2 minutes, and we timeout the win_wait_for_process after 3 minutes, we know exactly what is going on
20:11:38 <nitzmahone> That's why those async tests had to be disabled
20:12:16 * nitzmahone doesn't see how that solves the problem
20:12:26 * jhawkesworth_ trying to think if could bedge by renaming an .exe using a guid or something like than, and then looking for guid-named process
20:12:53 <dag> so basically we can't test waiting for a pid, then, so we are never going to merge the module ? :-)
20:12:55 <nitzmahone> you can't tell the difference between "the module didn't catch the exit properly" and "a PID was reused"
20:13:03 * jborean93 sorry I'm late, here now
20:13:42 <nitzmahone> We're not merging new modules without tests though
20:13:51 <dag> nitzmahone: it wouldn't be reused if the original PID still existed, why would a PID be gone before 10 seconds if it's a "sleep 10"
20:14:05 <dag> no, but I am proposing to write those tests
20:14:16 <dag> even the ones that are impossible to write ;-)
20:14:23 <nitzmahone> (PID 99: sleep 10) -> exits -> (PID 99: something else)
20:14:50 <dag> we know from "elapsed" if it was 10 seconds, or more than 10 seconds
20:14:53 <nitzmahone> If the poll occurs after the PID has been reused, the test will wait forever (or until timeout) and fail
20:15:10 <nitzmahone> You have to leave a lot of slop in there though
20:15:17 <dag> and if timeout is 20 and elapsed > 10 we know it's an error
20:15:23 <dag> correct
20:15:25 <nitzmahone> Ask Jordan- he's been working on fixing stability issues in async tests lately ;)
20:15:37 <dag> it'll not be 100% accurate, but I would expect it to be stable enough
20:15:53 <dag> but again, if it's impossible to test, should we not merge ?
20:15:56 <nitzmahone> dag: oh- you're saying to go back and check the async_result
20:16:00 <dag> because I can comment those tests out
20:16:23 <bcoca> seems wait_for_pid is not viable on windows, unless we can use another id that is
20:16:24 <jhawkesworth_> it'll probably work fine until next windows update installs a new .net version and you loose a cpu while ngen recompiles everything. grr
20:16:26 <nitzmahone> unless I missed something, there are no tests
20:16:31 <dag> nitzmahone: yes, and also win_wait_for_process result
20:16:52 <jborean93> the async tests seem to work fine but I haven't run the async stuff in the win_wait_for tests in a while so they may still be buggy
20:17:01 <dag> (22:14:05) dag: no, but I am proposing to write those tests
20:17:04 <jborean93> probably time to revisit them as we've changed the async process slightly in 2.7
20:17:08 <nitzmahone> Yeah OK, now I get what you mean- that should work for the test, though the module itself could still suffer from that in both the "present" and "absent" cases
20:17:15 <dag> (I feel like we ended up in some endless loop ;-))
20:17:37 <jborean93> the PIDs were reused :)
20:17:46 <nitzmahone> :D
20:17:47 <jhawkesworth_> please provide closing brackets
20:18:00 <dag> so, are we okay to merge the module with the notion that I write the tests ASAP (including the impossible tests, but commented out when they fail)
20:18:18 <jborean93> yep that's ok with me
20:18:34 <dag> ok :-)
20:18:34 <nitzmahone> I guess- probably also needs a note that "PIDs are reused aggressively on Windows, so YMMV"
20:19:00 <dag> I will be happy to run into that wall this night
20:19:02 <bcoca> no way to get a diff unique identifier that does not have that problem?
20:19:09 <dag> or prove everybody wrong !
20:19:12 <dag> :p
20:19:16 <nitzmahone> I haven't had time to look carefully at the RDP config modules, but at a glance looks OK
20:19:24 <jborean93> there's no tests IIRC
20:19:32 <jborean93> but that may be hard to do for some
20:20:02 <jhawkesworth_> controversially I wonder if the RDP stuff would be better in roles
20:20:09 <jhawkesworth_> on galaxy
20:20:38 <nitzmahone> Looks like the RDP stuff has some tests
20:20:48 * jborean93 stands corrected
20:22:16 * nitzmahone will try to look that one over and merge for 2.7 if it's good to go
20:22:25 <nitzmahone> #action nitzmahone to review https://github.com/ansible/ansible/pull/43406 for 2.7
20:22:57 <nitzmahone> At a glance anyway, they look like pretty decent modules over the RDP settings PS provider
20:23:23 * dag noticed jhawkesworth_ drank the galaxy Kool-Aid ;-)
20:23:55 <jhawkesworth_> :-)
20:24:07 <nitzmahone> #topic open floor
20:24:11 <nitzmahone> mind the gap
20:24:34 <jborean93> I'm planning on spending today to review all the PRs and go over the issues for low hanging fruit
20:24:52 <dag> the win_nssm cleanup looks very interesting
20:25:03 <dag> I think he fixed more issues than he listed in that PR
20:25:05 <jborean93> I saw a PR was raised but I haven't looked at it yet
20:26:36 <nitzmahone> Anything else for today?
20:26:40 <imjoseangel> Hey
20:26:51 <imjoseangel> I would like to ask about https://github.com/ansible/ansible/issues/24098
20:27:18 <imjoseangel> Just interested in adding that functionality or even create a new module
20:27:34 <imjoseangel> If nobody is working on that
20:27:40 <imjoseangel> If nobody is working on it
20:27:55 <jborean93> imjoseangel: not that I'm aware of, feel free to add that feature
20:27:58 <nitzmahone> @jborean93 I can't remember, is that stuff reasonably accessible?
20:28:11 <jborean93> it's been a while but IIRC WMI exposed it
20:28:35 <nitzmahone> Then yeah, go for it- probably same module
20:28:49 <jborean93> imjoseangel: One thing we would ask for is tests to cover the new features, feel free to reach out if you need help there
20:29:32 <imjoseangel> Yep, same as I did with vmware_guest_move.py I will check some already done and will contact if I have questions
20:29:43 <imjoseangel> Thank you!
20:30:01 <jhawkesworth_> thanks for working on this, it would a nice feature to have
20:30:05 <dag> imjoseangel: usually we don't have meetings here, except tuesdays at this time ;-)
20:30:08 <nitzmahone> Yeah, should be pretty easy to test- just get the PID of the test service and kill it with a couple of different recovery modes
20:30:11 <jborean93> looks like you can use https://docs.microsoft.com/en-us/windows/desktop/api/winsvc/ns-winsvc-_query_service_configa in Win32_Service
20:31:07 <imjoseangel> Cool! @dag, yep I realize about the time :P Thanks!
20:31:20 <jborean93> Once that's done I think the only remaining part left for win_service is a security descriptor control :)
20:31:39 * nitzmahone shudders
20:31:57 * dag doesn't even know what that is, but thinks of SELinux
20:31:59 <dag> instead
20:32:12 <jborean93> access control
20:32:23 <nitzmahone> let random non-admin manage service
20:32:23 <jborean93> contains the DACL, SACL, Owner and Group of an object
20:34:09 <nitzmahone> #action imjoseangel to investigate adding recovery controls to win_service
20:34:15 <nitzmahone> Anything else for today?
20:34:32 <dag> anything for Ansible v2.7 release ?
20:34:58 <jborean93> I'm good, unfortunately didn't achieve as much as I wanted for 2.7 but that's the way it goes
20:35:23 <nitzmahone> Community freeze is EoD Thursday, immediately followed by 2.7.0 Beta 1
20:35:43 <nitzmahone> (and branching of stable-2.7, so let the backports begin)
20:36:12 <jhawkesworth_> cool.  Can't keep up, not yet rolloed out 2.6!
20:36:59 <jhawkesworth_> Hoping I can be more help during 2.8.  light at end of the tunnol of current project
20:37:13 <nitzmahone> 👍
20:37:19 <jhawkesworth_> (hoping its not light on the front of the train) :-)
20:37:28 <imjoseangel> :P
20:37:29 <nitzmahone> heh
20:37:43 <nitzmahone> OK, well, if nothing else, ending meeting in 5...
20:37:48 <nitzmahone> 4..
20:37:51 <nitzmahone> 3..
20:37:53 <jhawkesworth_> cheers
20:37:54 <nitzmahone> 2..
20:37:56 <nitzmahone> 1..
20:37:57 <jborean93> thanks
20:38:00 <imjoseangel> Bye!
20:38:00 <nitzmahone> Thanks all!
20:38:03 <nitzmahone> #endmeeting