20:00:02 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:02 <zodbot> Meeting started Tue Mar 24 20:00:02 2020 UTC.
20:00:02 <zodbot> This meeting is logged and archived in a public location.
20:00:02 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:02 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:06 <jborean93> heh
20:00:18 <nitzmahone> #chair jborean93
20:00:18 <zodbot> Current chairs: jborean93 nitzmahone
20:00:18 <jborean93> was watching the seconds counter to see when you would do it
20:00:45 <nitzmahone> 2 seconds late!
20:00:45 <briantist> 👋
20:01:00 <jborean93> yea, totally could have beaten you to it :)
20:01:02 <jborean93> hey briantist
20:02:27 <nitzmahone> Once again nothing new on the agenda, so ...
20:02:34 <nitzmahone> #topic open floor (mind the gap)
20:03:01 <jborean93> I've got nothing to add, the win_service changes are in on the new collection
20:03:07 <nitzmahone> noice
20:03:28 <briantist> qq not directly related to Windows but.. it's on my mind so: is there any guidance on doc fragments that span collections?
20:03:46 <jborean93> Hoping to solve some of the setup bugs sometime soon but have a ffew other things I need to do first
20:04:06 <jborean93> Documenting changes in collections is still evolving, the docs team are working on a standard right now
20:04:26 <jborean93> But are you wanting to reference another collection in a change fragment?
20:04:34 <nitzmahone> briantist: collections can have deps, and so long as you use a FQCN for the doc fragment, should be fine, but I'd proceed with caution
20:04:47 <jborean93> oh sorry too early for me this morning
20:04:58 <jborean93> I would you were talking about changelog fragments
20:05:50 <briantist> in this case it's for the hashi_vault lookup plugin; I had a PR from before the merge that used the AWS doc fragment. This worked really nicely to bring in AWS connection params since plugins automatically load options based on docs, but it's broken now and I haven't had a change to look into if/how it can/should be done
20:06:18 <briantist> anyway just noticed based on the new test failure today; not anything to do with Windows at the momentm thanks!
20:06:23 <nitzmahone> That's probably a case where I'd just duplicate it, unless the plugin itself also depends on the collection
20:06:24 <jborean93> I would probably just manually document them
20:06:51 <nitzmahone> Otherwise the docs won't render properly if the collection where the fragment lives is missing
20:07:06 <briantist> cool, duplicating sounds right for now then, appreciate the insight!
20:07:17 <nitzmahone> But if it won't run properly either (eg it's using other code from the AWS collection) then it's probably fine
20:07:46 <briantist> it doesn't use any code, it was just unifying the connection params
20:08:51 <briantist> jborean93:  I've had some issues recently trying to use `psrp` with kerberos. I'm installing the `pypsrp[kerberos]` package and other dependencies, but I seem to get errors randomly in different environments, sometimes GSSAPI stuff
20:09:02 <briantist> sometimes an error about OID / in_seq or something
20:09:15 <briantist> for the latter I saw an issue you commented on about `python-gssapi` vs `gssapi`
20:09:46 <briantist> so I started uninstalling the former, and installing the latter, but doesn't seem to fix it all the time. Tried full reinstalls with `pip -I`,  etc.
20:10:11 <jborean93> python-gssapi is the older package that is not compatible
20:10:22 <jborean93> gssapi is the newer one (with the same Python namespace) that it should work on
20:10:35 <jborean93> if you get the error please let me know
20:11:26 <briantist> Right `python-gssapi` is the one I'm trying to get rid of in favor of the newer one. Wondering what might be causing the inconsistency though; trying to standardize pre-reqs and hoping to move our Windows workloads to `psrp`, and causing much pain right now especially since I seem to have weird intermittent dependency issues
20:11:34 <briantist> ok I will start to document more thoroughly
20:11:52 <briantist> thought I would check now in case you have any other off-the-cuff suggestions
20:12:32 <jborean93> yea I haven't seen it before but if you are having OID or issues like that then it shouldn't be sporatic errors
20:14:19 <briantist> ok, I'll see if I can get more consistent data. A lot of these are in Jenkins jobs and using venvs so it should be more isolated but different jobs are giving different results with the same code and I'm like 🤯
20:14:35 <briantist> I'll get back to you if I have something better/more repeatable to report, thanks
20:14:40 <jborean93> sounds good
20:15:51 <nitzmahone> Anything else for today?
20:15:58 <briantist> ah, one thing I would like to understand, when using `winrm` or `psrp` with kerberos, does it have any overlap at all with the settings used by `kinit` or `klist`?
20:16:01 * nitzmahone eyes leftover goulash hungrily
20:16:09 <briantist> like the credential cache?
20:16:35 <jborean93> psrp will use the cache if it's there but it doesn't use kinit like winrm does to get a fresh credential if you are explicit there
20:17:27 <briantist> oh very interesting.. that might be something to look into... I have a few more questions around all this actually. We can take it out of the meeting if that's better for everyone?
20:17:36 <jborean93> sounds good
20:17:43 <jborean93> I don't think there's anything left for the meeting
20:17:43 <nitzmahone> IIRC some of the kerb envvars can float through psrp just as with winrm/kinit
20:18:02 <nitzmahone> (the ones that are library specific vs tool-specific)
20:18:03 <jborean93> yep, it really just depends on how the underlying gss call works
20:18:16 <jborean93> IIRC the cache path was one of them
20:18:28 <nitzmahone> OK, until next week then!
20:18:30 <nitzmahone> #endmeeting