20:00:29 <jborean93> #startmeeting Windows Working Group
20:00:29 <zodbot> Meeting started Tue Sep 19 20:00:29 2017 UTC.  The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:29 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:31 <jhawkesworth_> bluejeans link is https://bluejeans.com/7480904391
20:00:40 <nitzmahone> o/
20:00:43 <dag1> o/
20:01:04 <jborean93> #chair nitzmahone jhawkesworth_ dag1
20:01:04 <zodbot> Current chairs: dag1 jborean93 jhawkesworth_ nitzmahone
20:01:32 <jhawkesworth_> hello
20:01:35 <nitzmahone> #info 2.4.0 has been released
20:01:47 <jhawkesworth_> yay for 2.4
20:02:06 <dag1> nwsparks BasicTheProgram were also online
20:02:40 <jborean93> how did the bluejean's go?
20:02:47 <dag1> Does v2.4.0 include the "become_user: SYSTEM" capability ?
20:02:58 <jborean93> dag1: no the PR hasn't been merged
20:03:04 <jborean93> will be for 2.5 once it does
20:03:05 <jhawkesworth_> bluejeans call is still active if you would like to join
20:03:11 <dag1> (me hears Jon typing in the background, so refrains from answering that one)
20:03:31 <jborean93> jhawkesworth_: sorry I'm not in a position to talk, my partner is asleep right now and I don't want to wake her up
20:03:37 <dag1> jborean93: no problem, it came up during the sprint
20:03:58 <dag1> so let me summarize Sprint 2 quickly
20:04:16 <dag1> we identified documentation issues with the different privilege issues on Windows
20:04:38 <dag1> a lot of people have issues that we suspect are related to privileges/interactive session etc.
20:05:00 <dag1> so it would be nice if we had integration tests that could test each of the individual rights/permissions so we can point users to that one
20:05:21 <dag1> and they can test it in their environment and report back for their user/system what works and what doesn't
20:05:40 <jborean93> are you talking about double hop issues, certain restrictions like WUA or interactive issues?
20:05:44 <jborean93> all or the above?
20:06:01 <dag1> but a general list of the different become/scheduled task/win_psexec, etc would already be nice to point users to to have them figure it out themselves and report back
20:06:07 <dag1> jborean93: all of the above :)
20:06:10 <jhawkesworth_> all of the above, plus winrm's own restrictions I guess
20:06:17 <dag1> yes
20:06:21 <jborean93> ok
20:06:32 <jborean93> good to know
20:06:56 <jborean93> I was planning on doing some doc stuff this week if nitzmahone didn't need me too much for pywinrm stuff
20:06:58 <jhawkesworth_> for info in the docs stuff I have a section on working around winrm restrictions.
20:07:11 <dag1> I think that one was the most important set of items on my list, there are a few we have to reproduce or need more info from
20:07:14 <jborean93> but if you guys have a PR/wiki page with stuff already that would be great
20:07:37 <dag1> jborean93: I guess we can list a few ideas, and link to relevant PRs for that
20:07:54 <dag1> but I am not the person to write this :-)
20:07:55 <jborean93> ok, I'll try and start one up and we can all contribute to it
20:08:06 <jhawkesworth_> thank you
20:08:10 <dag1> as in "no clue whatsoever"
20:08:41 <dag1> (I don't hear Jon laughing in the background, so it's serious)
20:08:57 <dag1> he just choked even
20:09:06 <jhawkesworth_> i have a cold!
20:09:18 <dag1> yeah right :)
20:09:30 <dag1> so let's move to the actual meeting
20:09:35 <jborean93> cool, anything else that came up in the sprint?
20:09:50 <dag1> I don't think we fixed a single thing this Sprint :-)
20:10:05 <dag1> but I call it a day at 24:00 CEST, so still 2 hours to go ;-)
20:10:16 <jhawkesworth_> I'll be on for a while yet too.
20:10:26 <dag1> ah, I can extend if needed
20:10:30 <jborean93> a lot of the remaining issues are either quite complex to deal with, cannot really reproduce but are possible issues or somewhat environment setup issues
20:11:02 <dag1> right, normally I would ask for a minimal reproducer, but in this case the minimum is there, we just can't reproduce ;-)
20:11:09 <dag1> these cases
20:11:31 <jborean93> for the agenda the only thing that hasn't been crossed out is https://github.com/ansible/community/issues/195#issuecomment-328310659 but I thought we talked about this last week. Anything else you wanted to talk about dag1 on this?
20:12:13 <dag1> Well, I wondered if reboot_required is the same thing as ansible_reboot_pending ?
20:12:44 <dag1> if a task returns reboot_required, is the ansible_reboot_pending also set, or could there be different causes
20:13:08 <jborean93> well if we were to add that fact and update it accordingly I would have thought it would
20:13:08 <dag1> like an installer making his wish known, and a windows update actually forcing the system to reboot within a certain time
20:13:19 <jborean93> if a reboot is required then in my mind it is pending also
20:13:43 <dag1> right, but I wasn't sure if every module that returns this also updates the system's state regarding this
20:13:44 <jhawkesworth_> I don't think we have a way of saying 'windows is going to force a reboot on you in x mins yet'
20:13:50 <dag1> it might be, I don't know Windows too well
20:14:15 <jborean93> I've never seen that fact, plus there isn't a single common reboot required flag that I know off
20:14:16 <dag1> jhawkesworth_: well actually, if you do a win_reboot on a machine that has a reboot scheduled, it fails
20:14:32 <dag1> so that's actually possible (and not necessarily related to reboot_pending I guess)
20:14:34 <jborean93> Some reg entries and maybe WMI can tell you but alst time I tried it was hit and miss
20:14:45 <dag1> ok
20:14:56 <nitzmahone> My thought on that flag was that if we're going to update the fact, it should always be done from a shared piece of code- otherwise, you have the potential for it to "flap"
20:14:57 <dag1> we can test this obviously
20:15:28 <jborean93> we just need to hope installs that require it also trigger that flag somewhere
20:15:34 <dag1> otherwise we end up with ansible_reboot_required, ansible_reboot_pending and ansible_reboot_scheduled :-D
20:15:34 <nitzmahone> Everything I know of that truly needs a reboot can be sampled via reg
20:16:07 <BasicTheProgram> I am back
20:16:08 <dag1> jborean93: right, and that we can test ourselves, and even expose a warning if it doesn't work as we expect
20:16:17 <dag1> ok
20:17:00 <jhawkesworth_> BasicTheProgram - windows working group meeting - discussing https://github.com/ansible/community/issues/195#issuecomment-328310659
20:17:03 <jborean93> I believe nitzmahone was potentially looking at automated reboots if `reboots_required` was set on the return value, unless I am mistaken?
20:17:04 <dag1> ok, let's drop this subject since we need to discuss this with the core team IMO
20:17:13 <nitzmahone> I have some ideas about how to rearchitect facts to allow for:
20:17:13 <nitzmahone> a) pluggability
20:17:13 <nitzmahone> b) granular callability
20:17:13 <nitzmahone> c) performance
20:17:21 <nitzmahone> (when we get there)
20:17:23 <dag1> \o/
20:17:55 <jhawkesworth_> will be interested to hear your thoughts about facts
20:18:09 <dag1> I really wanted to have that discussion at AnsibleFest SF, but it requires preparation and I am not confident I see it all
20:18:55 <nitzmahone> and yes, I originally had that behavior in the win_reboot action that I scrapped before merging what we have
20:19:10 <dag1> so anotherquestion !
20:19:12 <nitzmahone> s/win_reboot/win_updates/
20:19:22 <dag1> what is the v2.5 roadmap for Windows ?
20:19:24 <nitzmahone> and looked at potentially including it in a base action
20:19:25 <jhawkesworth_> yeah I don't actually use current facts much so feel like I am missing how others use facts
20:19:38 * nitzmahone consults notes
20:19:46 <dag1> full disclosure !
20:20:00 <nitzmahone> - C# argspec
20:20:13 <nitzmahone> - PSScriptAnalyzer in ansible-test
20:20:18 <nitzmahone> - Pester in ansible-test
20:20:36 <nitzmahone> - Platform abstraction for mix/match connection/shell plugins
20:20:56 <nitzmahone> - Become flags
20:20:57 * dag1 hears Jon making whooping sounds
20:21:22 <jhawkesworth_> what is a 'become flag'?
20:21:29 <nitzmahone> That's all on my personal pet project list (other than continuing to mess with native Win32 Python Ansible controller )
20:21:52 <jborean93> jhawkesworth_ you can adjust the become method flags in a particular way
20:21:56 <nitzmahone> Basically being able to set options on become like, "do a service/batch/whatever logon", "don't try to elevate", etc
20:21:57 <dag1> how about a multi-threaded Ansible ? :)
20:22:01 <jborean93> right now it is hard coded to logon as interactive
20:22:13 <nitzmahone> dag1: That's prereq for a Windows controller- we already have a test branch
20:22:58 <nitzmahone> https://github.com/ansible/ansible/tree/threading_instead_of_forking
20:23:31 <jborean93> I wanted to spike out SSH and Windows but that probably will rely on the platform abstraction work so not sure if it will make it in. Also having a flag in the module that says `#Requires -become` (or something like that) so it runs in a non WinRM state
20:23:41 <dag1> how about the new argument_spec and module interface, I know something was done, how far is it from being done ?
20:24:07 <nitzmahone> Yeah, if we get platform built as I expect, Win/PS/SSH will be the #1 acceptance test
20:24:15 <BasicTheProgram> I had a couple issues with quotes and args, I think jborean93 talked about changing how args are passed (looking for the issue) where the comment was made.
20:24:22 <nitzmahone> dag1: That was the first thing on my list up there
20:24:28 <dag1> nitzmahone: I know, but Windows controller is probably not on the roadmap ;-) whereas multi-threaded Ansible does offer some advantages to Linux too
20:24:50 <dag1> nitzmahone: I see
20:25:12 <nitzmahone> I still need to implement recursive subspec and a couple other things (and clean it up), but "early in 2.5" is my plan. Hoping we can convert most/all modules to use it in 2.5 as a real acid test for it.
20:25:28 <jhawkesworth_> that would be great
20:25:36 <dag1> more joy !
20:25:38 <nitzmahone> dag1: right- Jimi wasn't thinking Windows when he did that, but I sure was ;)
20:25:42 <jborean93> BasicTheProgram: it was changed here https://github.com/ansible/ansible/pull/30253
20:25:43 <jhawkesworth_> I'll probably find loads of errors in my playbooks
20:26:10 <dag1> nitzmahone: Can we add that list to the Wiki somewhere so other people can see what's coming (or at least planned)
20:26:14 <nitzmahone> jhawkesworth_: that's the idea- it'll be great to have "bogus arg" validation at least
20:26:19 <nitzmahone> s/least/last/
20:26:33 <nitzmahone> dag1: it'll be on the official roadmap this week I believe
20:26:41 <BasicTheProgram> Thanks jborean93 I didn’t see that PR
20:26:44 <nitzmahone> (not much sense in duplicating on wiki IMO)
20:27:09 <nitzmahone> Once it's in there, we can put a tasklist for "modules needing conversion/test" on the wiki
20:28:00 <nitzmahone> Roadmap is a little behind since Dylan's been on baby duty, but I think we're nailing it down this week
20:28:57 <jhawkesworth_> great
20:29:05 <dag1> I think there's some benefit to have things in a single place, but no problem
20:29:23 <dag1> we have the roadmap linked from the Wiki Plan page, people just might not find it
20:29:32 <nitzmahone> Though I guess once the roadmap's locked we could have more granular status on our wiki
20:29:52 <nitzmahone> Just don't want to be updating things in multiple places
20:30:21 <dag1> I understand
20:30:33 <jhawkesworth_> agreed.  update the roadmap if it has changed though.  Stuff changes
20:32:12 <nitzmahone> Anything else to chat about today?
20:32:33 <dag1> maybe we could go over https://github.com/ansible/community/wiki/Windows:-action-list and clean it up ?
20:33:15 <jhawkesworth_> good idea
20:33:17 <dag1> it may give some food for thought for the v2.5 roadmap too, so we don't miss out on anything if the roadmap is locked :p
20:33:29 <nitzmahone> good call
20:33:39 <nitzmahone> Who's going to do the actual edits?
20:33:48 <nitzmahone> (so we're not tripping on each other)
20:33:51 <dag1> yeah :)
20:34:01 <dag1> Github Wiki conflict detection is non-existing :-(
20:34:07 <nitzmahone> exactly
20:34:09 <jhawkesworth_> I am happy to
20:34:32 <dag1> so easy to implement (just keep the previous version and check it on commit)
20:35:15 <nitzmahone> Powershell coding style/syntax is on me now- I've got it working locally, just need to clean up and merge
20:35:29 <nitzmahone> (and set the initial ignore list)
20:35:53 <jborean93> I was going to look at refactoring some tests to speed it up. Not sure how successful I will be
20:36:04 <dag1> Is "-Upstream win_oneget -- trondhindenes" still relevant ?
20:36:41 <jborean93> I believe parts of it is
20:36:54 <jborean93> Unfortunately oneget is pretty confusing from an implementation perspective
20:37:15 <jborean93> the chocolatey provider isn't even official
20:37:23 <nitzmahone> We merged pspackage/psmodule thing right? That's most of it, IIRC
20:37:27 * nitzmahone looks
20:37:47 <jhawkesworth_> I am working on a visualization for 'Work out matrix of options wrt. ConfigurRemotingForAnsible.ps1'
20:37:58 <jborean93> psmodule is in
20:39:04 <jhawkesworth_> Implement #AnsibleRequires functionality is done, I'll cross that out
20:39:06 <nitzmahone> Something else for me for "individual actions" is to merge the winrm connection plugin docs
20:39:07 <jborean93> `Ensure service accounts don't need NT AUTHORITY\ prepended for convenience` is done if you use the new module utils
20:39:44 <nitzmahone> jhawkesworth_: it's not- #AnsibleRequires is for req's other than module_utils
20:40:07 <nitzmahone> (eg, OS version, "module requires become", etc)
20:40:14 <jborean93> nitzmahone: are these docs already created and just need editing
20:40:18 <jhawkesworth_> ah ok I see what you mean, I'll leave that
20:40:34 <jborean93> what exactly are they in particular?
20:40:56 <nitzmahone> jborean93: Yeah, I wrote them last year- they're just sitting on my Google drive in a spreadsheet needing transformation to YAML
20:41:11 <jborean93> YAML? not RST
20:41:22 <nitzmahone> Plugin docs are all YAML
20:41:29 <nitzmahone> (like module docs)
20:41:55 <nitzmahone> `ansible-doc -t connection -a`
20:42:22 <nitzmahone> I was trying to get it done for 2.4.0, but some late-breaking Azure stuff screwed me up.
20:43:16 <dag1> Maybe we could add something like "- Implement a solution for updating facts from modules granularly (?)" so we keep tracking that too
20:43:35 <bcoca> they get converted to rst for webpage, but 'embeded docs' are YAML
20:43:45 <jborean93> nitzmahone bcoca: ah ok, probably need to at those docs a bit closer
20:44:01 <dag1> so bcoca is lurking again ;-)
20:44:08 <dag1> he's like God
20:44:09 <bcoca> im always lurking
20:44:18 <bcoca> dont demote me!!  I AM ROOT
20:44:26 <dag1> :-)
20:44:43 <jhawkesworth_> right I think I have saved all changes discussed above
20:45:08 <dag1> where are we with Windows 2016 support for testing ?
20:45:14 <dag1> (And may I add Windows 10 support :p)
20:45:47 <dag1> Windows 2016 (and maybe Nano ?) is becoming more and more important
20:45:49 <nitzmahone> Windows 10 CI is probably not going to happen anytime soon- we'd have to maintain images
20:45:56 <dag1> yeah
20:45:59 <dag1> bummer
20:46:07 <jhawkesworth_> slightly related to that I think there was a plan to make the s2012r2 use PS 5.1 and keep s2012 on PS 4.
20:46:12 <jhawkesworth_> shall I put that on the list?
20:46:17 <nitzmahone> But 2016 will, one way or another. Currently blocked on pywinrm update
20:46:51 <nitzmahone> (since it hits the HTTPS wedging problem, we'll have to do 2016 w/ NTLM or CredSSP over HTTP)
20:47:11 <jborean93> not a bad thing, means we test another matrix option
20:47:13 <nitzmahone> Hoping to kick out a pywinrm beta this week, so we can add 2016 with that at that point
20:47:16 <dag1> Also mattclay has a (test?) PR open where he separated the different Windows targets in Shippable, I would really like that
20:47:17 <nitzmahone> exactly
20:48:06 <jhawkesworth_> interesting, that will kill using S2016 for us.
20:48:26 <nitzmahone> ?
20:48:43 <jborean93> why is that?
20:48:57 <jhawkesworth_> I can't imagine us not using kerberos / https
20:49:22 <jborean93> this is just for testing, I've been using 2016 with Kerberos locally fine
20:49:35 <nitzmahone> That's what the pywinrm beta will fix (so we can do encrypted NTLM/Kerb/CredSSP over HTTP)
20:49:37 <jborean93> plus nitzmahone has a HTTP Kerberos encryption PR as well floating somewhere
20:49:48 <jhawkesworth_> ah ok
20:50:25 <nitzmahone> Jordan got NTLM/CredSSP encryption working, and I have kerb working- we just need to merge them all together and get the necessary upstream bits shipped
20:51:06 <jhawkesworth_> that's great - so this is the content of next pywinrm?
20:52:05 <nitzmahone> ye
20:52:08 <nitzmahone> *yep
20:52:45 <nitzmahone> That and fixing the damned error messaging to include the SOAP fault data on 500s when present
20:53:17 <dag1> Just do it !
20:53:18 <jborean93> not that they are very helpful
20:53:18 <nitzmahone> Plus a few other things. We should probably move the send_input stuff in there
20:53:19 <jhawkesworth_> that will be good to have too.
20:54:49 <dag1> alright, good stuff for the lurkers to read in the logs tonight/tomorrow !
20:55:58 <jborean93> cool, nothing else pressing
20:56:00 <jborean93> 1
20:56:02 <jborean93> 2
20:56:03 <jborean93> 3
20:56:21 <nitzmahone> lol- was wondering how far up we were counting ;)
20:56:26 <jborean93> just 3
20:56:36 <jborean93> plus a bit of extra time because it was pretty quick
20:56:47 <jborean93> cool, the tribe has spoken
20:56:50 <jborean93> #endmeeting