20:01:14 <nitzmahone> #startmeeting Windows Working Group
20:01:14 <zodbot> Meeting started Tue Jul 11 20:01:14 2017 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:14 <zodbot> The meeting name has been set to 'windows_working_group'
20:01:25 <jhawkesworth_> hello
20:01:51 <nitzmahone> #info agenda: https://github.com/ansible/community/issues/153
20:02:35 <jborean93> hello
20:02:49 <nitzmahone> #chair jhawkesworth dag jborean93
20:02:49 <zodbot> Current chairs: dag jborean93 jhawkesworth nitzmahone
20:03:14 <pablodav> hello everyone
20:03:21 <jborean93> hey, welcome
20:03:24 <jhawkesworth_> hey
20:04:16 <pablodav> hi!, I'm just sitting here today to watch and learn how you do these meetings
20:04:50 <jborean93> #topic Windows setup facts
20:04:51 <jborean93> https://github.com/ansible/community/issues/153#issuecomment-312738930
20:04:59 <dag> o/
20:05:05 * nitzmahone digs through agenda ticket- probably time to declare bankruptcy and start a new one soon
20:05:16 <dag> haha
20:05:26 <jborean93> I would say it is time, just lucky I had it prepared :)
20:05:40 <dag> Let me know and I'll do the necessary admin work
20:05:48 <jborean93> basically there are a few PR's and Issues floating around with either adding facts or fixing existing ones
20:06:07 <jborean93> I'm hoping to get a consensus about when we add facts and/or when we push people to use their own fact scripts
20:06:26 <nitzmahone> Does this include adding support for gather_subset? That's a feature parity thing we need to do too...
20:06:49 <dag> I think performance is one good reason
20:07:10 <nitzmahone> If we have gather_subset support, it becomes *slightly* less an issue since folks can opt out, but at some point the size of the setup module is a concern, too.
20:07:18 <dag> I have a feeling that the Windows setup module is slower than on Linux (but it could be winrm playing a bigger part)
20:07:52 <jhawkesworth_> windows setup definitely feels slower for me.
20:08:10 <nitzmahone> Yeah, I think there are a couple of compatibility things that can slow it down, too
20:08:19 <jborean93> there are a lot of things it gathers, I need to look at it but definitely not the quickest
20:08:41 <nitzmahone> (eg, Get-WmiObject vs Get-CimInstance)
20:08:45 <jhawkesworth_> but winrm boat load faster than it used to be, so I'm much less fussed about runtime now.
20:08:54 <jborean93> I'm wary of adding more in the case we do move to gather_subset
20:09:45 <nitzmahone> Well, the gather_subset allows you to shut parts off
20:09:59 <nitzmahone> But it might be good to do that all at once
20:10:19 <dag> gather_subset is not a free ticket for adding whatever IMO
20:10:23 <nitzmahone> agreed
20:10:34 <dag> it should be 1. generally useful 2. efficient
20:10:53 <jborean93> ok, so sounds like we hold off adding stuff to Windows facts until we start supporting gather_subset?
20:11:20 <nitzmahone> Related question: do we want to do that for 2.4? It's not on the roadmap, but that's mainly because I keep forgetting about it
20:11:34 <jhawkesworth_> sounds like a reasonable position.
20:11:34 <dag> unless it is fast/free and very useful to have in general
20:11:38 <nitzmahone> 2.4 engine freeze is August 15 and module freeze is August 28
20:11:39 <jborean93> I'm happy to take a stab at it
20:11:52 <nitzmahone> WFM
20:11:54 <jborean93> #action jborean93 to implement gather_subset for windows facts
20:12:12 <jborean93> #topic https://github.com/ansible/community/issues/153#issuecomment-312966236 backup support
20:12:12 <jhawkesworth_> would gather_subset be something implemented using win equivalent of shared module code?
20:12:14 <nitzmahone> Then we can look at the individual enhancement requests and see what's worth doing
20:12:21 <dag> Do we have a list of facts that we lack (compared to python) or a list of facts that we really should have ?
20:12:38 <nitzmahone> Nah, just basically a standard arg to setup to allow it to shut off parts (eg, disk/network)
20:12:43 <dag> Might be useful to start collecting this too, so we can draw a clearer line ;-)
20:13:37 <jborean93> sounds like comparison work we should document changes for and work to reduce the differences
20:13:39 <nitzmahone> Hard part there is that python side is very OS/distro/installed tool-dependent. I can't even get buyoff to include it all in RETURN docs, so it's basically "you have to go look at the code or run it on your platform of choice" to see what it might return.
20:14:23 <dag> jborean93: unfortunately we do have some inconsistencies too, but also some bad python setup stuff we should overhaul and do correct from the start
20:14:46 <nitzmahone> dag filled in some holes there for 2.3
20:15:10 <jborean93> that sounds fine, as long as they are close, we can never get 100% due to differences in how the OS works
20:15:20 <dag> jborean93: sure
20:15:45 <nitzmahone> We also need to be careful about admin requirements in setup
20:15:47 <dag> I think what we have is quite good though, except for disk-related stuff, I didn't need anything else
20:15:50 <jhawkesworth_> i toyed with returning installed windows packages in facts but... they are so inconsistent anyway.
20:16:05 <nitzmahone> ... and can be slow to collect
20:16:18 <nitzmahone> The Windows Tower scan job collects that IIRC
20:16:23 <dag> jhawkesworth_: seems to be a perfect example to add as a seperate _facts module
20:16:40 <jhawkesworth_> makes sense.
20:16:40 <jborean93> I think we should try and encourage the fact_path and document more on how that works
20:16:54 <pablodav> comment about the facts received from setup: I had to keep my own output because never found an documented output of facts
20:17:00 <jhawkesworth_> for some reason I do very little reasoning in playbooks with windows facts.
20:17:02 <nitzmahone> Or just encourage people to do custom fact modules
20:17:17 <nitzmahone> I disable fact gathering like 95% of the time
20:17:26 * dag is still hoping to get a better fact-system implemented, so people can add their own facts plugins into a directory to be added to the normal setup phase
20:17:27 <nitzmahone> If I need something, I'll call setup explicitly.
20:17:40 <bcoca> nitzmahone: change gathering: explicit in config
20:17:50 <dag> some $CUSTOMER have their own specific needs to their setup/applications
20:17:53 * nitzmahone rarely runs with a config file either though
20:18:12 <dag> nitzmahone: but you are special ! ;-)
20:18:13 <jborean93> yea we used things like ansible_domain where I was for environment stuff
20:18:14 <bcoca> nitzmahone: also env var
20:18:55 <dag> #action We make a list of possible missing/new facts in the Wiki
20:19:00 <nitzmahone> +1
20:19:06 <jborean93> +
20:19:14 * jborean93 forgot to turn numlock on
20:19:18 <nitzmahone> lol
20:19:25 <nitzmahone> +[end]
20:19:36 <jborean93> cool next topic around the backup parameter
20:20:03 <jborean93> dag you have the floor
20:20:04 <nitzmahone> I haven't looked to see which *nix modules support that explicitly- IIRC just template and lineinX?
20:20:13 <dag> yeah, so this came up as part of the xml module
20:20:43 <nitzmahone> But I think it's a fine idea...
20:20:43 <dag> and we should have basic backup-infrastructure that all the other modules can use (win_copy, win_template, win_lineinfile, win_get_url)
20:21:09 <jhawkesworth_> sounds like a great thing to put in shared module code
20:21:14 <dag> richardcs proposed to do this
20:21:28 <dag> and this will bring us closer to feature parity with python modules
20:21:29 <jborean93> same, I'm just wary of adding more to powershell.ps1 when the modular side is coming in
20:21:30 <nitzmahone> I'll commit to shipping the module_utils plugin loader
20:21:51 <nitzmahone> I'll shoot to have it in before this meeting next week
20:21:59 <dag> yeah, I think it's more important to have this written and discussed, and as soon ad we have the modular powershell.ps1 we can retrofit that in
20:22:06 <jborean93> #action nitzmahone to work on module_utils plugin loader before next week
20:22:09 <jhawkesworth_> that would be awesome.
20:22:11 <dag> nitzmahone: even better
20:22:34 <jborean93> dag everything we add in there we need to keep going forward for some time
20:22:42 <nitzmahone> The assembly/usage side is the hard part, and that's been in since 2.3
20:22:42 <jborean93> trying to avoid that as much as possible
20:22:44 <jhawkesworth_> as long as one module has implementation we like can move it
20:22:44 <dag> I wasn't expecting any objections, but maybe you have insights for the implementation
20:23:07 <nitzmahone> So long as we remember to move it before 2.4 ships, I have no problem if it's built on powershell.ps1 and moved
20:23:10 <dag> jborean93: we can discuss the PR and amend without merging, and then retrofit into the new stuff
20:23:37 <jborean93> I think if we want the module in we should just have the backup code in that module and then we refactor out
20:23:49 <dag> I don't see a good reason to hold things off (especially since this was announced for some time now ;-))
20:24:09 <dag> jborean93: it's like that now, but I'd prefer a common approach from the start myself
20:24:29 <dag> and we may want to discuss the format of the backup file, not sure if the python default makes sense in a windows world
20:24:43 <dag> (wrt. extension and filename-parts)
20:25:04 <dag> maybe Windows has a very good convention and functionality for this that other applications are using
20:25:21 <nitzmahone> I'd say build the PR on powershell.ps1 and don't merge it
20:25:48 <bcoca> i would suggest creating a file.ps1 for 'file related functions' ... this is something we did wrong by putting everything in basic.py
20:26:06 <bcoca> so 'backup' and 'creates/removes' features would belong there
20:26:10 <nitzmahone> Then we'll rebase the PR once the PS module_utils loader is in and move the backup stuff to its own file.
20:26:10 <dag> bcoca: yes
20:26:21 <nitzmahone> Yep- what bcoca said
20:26:34 <dag> We also are lacking in the file-related departement
20:26:48 <bcoca> also, backup returns 'backup_file' key in results to allow 'playbook' to fetch/copy the file for 'centralized storage'
20:26:58 <dag> the python modules allow to set ownership/permissions etc for almost all file-relates modules
20:26:59 <nitzmahone> +1000
20:27:10 <bcoca> a bit harder with windows .. acl
20:27:11 <dag> bcoca: yes !
20:27:34 <nitzmahone> Not really, but that's again stuff that will be much easier to do with shared module code
20:27:35 <bcoca> but we do have acl module in unixland ... should make that and selinux/xattr default also in filemanagment (if enabled/existing/)
20:27:43 <nitzmahone> We have a decent YAML definition of Windows ACLs.
20:28:02 <nitzmahone> So if we share the code that consumes that, we can plug it in wherever it's needed.
20:29:05 <jborean93> ok so we are happy with how we want to approach the backup parameter for win_xml?
20:29:28 <nitzmahone> I think so: want me to action that?
20:29:42 <jborean93> I've got one already on your for module_util plugin
20:29:56 <nitzmahone> yeah, I meant the rest of it
20:30:00 <jborean93> sure
20:30:41 <jborean93> cool, next topic
20:30:50 <jborean93> #topic https://github.com/ansible/community/issues/153#issuecomment-312974050 windows sprint
20:31:01 <nitzmahone> #action @richardcs to propose shared backup code in win_xml PR via powershell.ps1 - we'll hold off merge until shared module_loader is available then rebase and move to separate file handling module_util file
20:31:40 <dag> so, what do people think about the sprint we did ?
20:31:46 <nitzmahone> How did you guys feel the sprint went? I think I'd like to leave that a "community-driven" activity
20:31:55 <jborean93> I thought the sprint was fine, my only feedback would be to reduce the amount of work we wanted to do and really focus on it
20:32:24 * jborean93 needs to be on a more powerful computer before doing it again
20:32:35 <dag> jborean93: the feature ideas were an oversight of my part, but on the upside, most of those have been implemented now too ;-)
20:32:46 <jhawkesworth_> good point.  I know we had some hitches but it took a while just to go through the PRs.
20:32:48 <nitzmahone> My general opinion on that is that if there's someone (dag, jon, whoever) that wants to organize and run those regularly, great, and we (Ansible, Inc folks) might or might not participate given time constraints.
20:32:57 <dag> https://github.com/ansible/community/wiki/Windows:-sprints
20:33:27 <jhawkesworth_> I feel like intention is that it should be community taking load off core team.
20:33:46 <jhawkesworth_> but thanks jborean93 for big cleanup of win_regedit
20:33:51 <dag> well, my number 1 reason is to get more people involved
20:34:17 <dag> and I do think we need core people involved to make it (more) successful
20:34:27 <nitzmahone> Yeah- I think it can be a great way to get more attention on modules that we won't have b/w to maintain but that are still important to the community
20:34:32 <dag> to give it some more weight for newcomers to join
20:35:26 <jborean93> I don't think I could do them if they were weekly but as an adhoc or more sporatic task I'm happy to help
20:35:41 <jborean93> but as nitzmahone say would depend on my current workload
20:35:47 <nitzmahone> I'm not going to say we *won't* participate, but I'll also say we'll probably get pushback if we're committing to them regularly.
20:36:15 <dag> we do need to close more issues if we want to get the queue emptied
20:36:26 <dag> (emptied is the optimistic lookout ;-))
20:36:33 <jborean93> I'm trying to get through those
20:36:44 <dag> the PR queue is increasing now faster too ;-)
20:36:46 <jborean93> a few are duplicated/people not responding/waiting on some stuff
20:37:05 <nitzmahone> We're working on better ways to deal with that on Ansible (paid) team as a whole too, but mostly for things that are tagged support:core
20:37:36 <nitzmahone> Doubling the size of the Windows team should help ;)
20:37:48 * dag still waiting for the badge-support to be merged, so we can make those numbers more upfront ;-)
20:38:16 <dag> for the Spinrts, we do need a better working BlueJeans
20:38:38 <dag> it's really important we can speak up while looking at stuff
20:38:49 <dag> IRC or BlueJeans chat is a bit distractor
20:38:55 <nitzmahone> Might do better with like Google Hangouts or something
20:39:12 <nitzmahone> For the size we're currently talking, it'd probably be easier
20:39:26 <dag> possibly, we'll experiment
20:39:43 <jhawkesworth_> yep worth a try
20:39:46 <nitzmahone> We don't have a way to easily hand off a Bluejeans session to someone else on a regular basis without breaking it for ourselves
20:39:47 <dag> we also had issues at the start with infrastructure, both me and Jon struggled with that
20:40:07 <jhawkesworth_> yeah. dag needs windows vms!
20:40:19 <dag> and that's for me a general theme with Windows development, I am always waiting for CI
20:40:32 <dag> jhawkesworth_: and Windows media
20:40:43 <jborean93> dag just download the evaluation ISOs
20:40:50 <nitzmahone> That shouldn't be an issue- have you played with packer-windows?
20:40:57 <dag> nitzmahone: no
20:41:01 <jhawkesworth_> get $current_employer to purchase msdn
20:41:03 <nitzmahone> Only way to fly
20:41:24 <dag> jhawkesworth_: problem is that I am completely disconnected from $CUSTOMER environment (Z laptops)
20:41:27 <dag> 2 laptops
20:41:33 <nitzmahone> jhawkesworth: I have a blank check to buy MSDN whenever I need it, but I haven't needed it in 2 years since I started usign packer-windows
20:42:23 <jhawkesworth_> ooh. will investigate
20:43:14 <nitzmahone> About once a year I'll redo my vagrant boxes just to refresh on updates- Matt Wrock also has a technique for auto-sysprepping after first boot that can be used to refresh the licensing on the trial ISOs so it's fresh 180d right out of the box.
20:43:34 <nitzmahone> I just hate that he uses Chef to build his instances ;)
20:43:43 <dag> maybe we should put this info up on the development guide as well ?
20:43:54 <jborean93> IIRC you can only use sysprep to reset that trial so many times?
20:44:25 <nitzmahone> You don't even need sysprep for that, but you can get over a year out of a trial instance (and since they're vagrant boxes, I usually redo them every couple months anyway)
20:44:29 <dag> Ok, so if people could look at https://github.com/ansible/community/blob/master/SPRINTS.md and amend where needed
20:44:32 <dag> I'm a happy camper
20:44:32 <nitzmahone> (slmgr /rearm)
20:45:12 <jborean93> cool is there anything else we wish to discuss around the sprints?
20:45:24 <dag> BTW we should have started the sprint with asking who opened one of the issues, because we didn't do some in the end owned by someone in the room
20:45:47 <pablodav> I agree could be good to have this packer-windows in development guide, I'm just starting and it sound very useful
20:46:25 <dag> and maybe do the Ansible integration tests with packer ?
20:46:53 <dag> that integration would be real nice
20:47:05 <nitzmahone> You can run them locally that way (using vagrant/vbox/vmware boxes built via packer)
20:47:09 <nitzmahone> I already do
20:48:09 <nitzmahone> Matt Wrock's got some nice (more modern) patterns too at https://github.com/mwrock/packer-templates
20:48:24 <nitzmahone> But he's using boxstarter/chef for a lot of stuff (since, well, he works for chef)
20:48:34 <nitzmahone> His 2016 stuff is all chef
20:48:55 <dag> ok, we're almost nearing 23PM here, let's continue the meeting
20:49:13 <jborean93> ok
20:49:22 <nitzmahone> #topic https://github.com/ansible/community/issues/153#issuecomment-313378484
20:49:22 <jborean93> #topic paths and windows
20:49:35 * jborean93 was too slow
20:49:50 <nitzmahone> heh
20:50:10 <dag> So that's one of the first actions out of the Sprint, finally writing that documentation related to Windows paths
20:50:37 <jborean93> I think what dag and jhawkesworth_ is good so far. I'm don't know how much we want to focus on the legacy format though considering all the issues that arise when we use it
20:50:38 <dag> indirectly this lead to: https://github.com/ansible/ansible/issues/26623 and https://github.com/ansible/ansible/pull/26490
20:51:03 <dag> jborean93: the legacy format is the mostconvenient for the ansible cli
20:51:09 <jhawkesworth_> misleading to call it 'legacy' format key=value not going away as needed for ad-hoc
20:51:21 <nitzmahone> +1 to "apply caution tape liberally to k=v format"
20:51:30 <dag> yeah, we now call it the key=value format ;-)
20:51:57 <dag> I'll remove the "legacy" there
20:52:24 <dag> there's one more complication, which is Jinja2
20:52:26 <jborean93> I'm happy with what is there, probably best to get it in and we can change accordingly as we find out more or need to tweak something
20:52:32 <dag> Jinja2 works differntly
20:52:49 <jhawkesworth_> I had a go at writing much the same in a more prescriptive style here: https://github.com/ansible/community/wiki/Windows-Paths---prescriptive-style
20:53:03 <dag> In Jinja2 you have to escape backslashes, even when using single quotes
20:53:17 <dag> jhawkesworth_: +1
20:53:42 <dag> so the idea is that we move the general information somewhere in the platform-independent docs
20:53:59 <dag> and use the prescriptive style docs in the Windows docs (with a reference to those details)
20:54:01 * nitzmahone is booking travel concurrently with running this meeting, so will be distracted for a few minutes
20:54:21 <jhawkesworth_> I doubt we can do anything about the way jinja2 behaves, which would be my preference, just have to add 'when using jinja2 templating' section I guess
20:54:39 <jborean93> yep the best we can do is document it
20:55:09 <dag> #action Dag will make a PR out of this if he finds the correct location to put the pieces
20:55:38 <jborean93> wary of time will move on unless there is anything pressing
20:55:46 <jborean93> #topic https://github.com/ansible/community/issues/153#issuecomment-313718853 -LiteralPath
20:56:07 <dag> Should we modify (most) modules to use -LiteralPath instead ?
20:56:14 <jborean93> what are the benefits
20:56:23 <dag> That globs are not supported
20:56:24 <jhawkesworth_> I suggest DetailedGuides -> Windows
20:57:05 <jborean93> If you swap to -LiteralPath you might get unexpected outcomes
20:57:14 <jborean93> I prefer the path type does the check and fails if it doesn't conform
20:57:17 <dag> Now we do Test-Path -Path C:\foo\bar, but that allows C:\foo\bar\*
20:57:46 <dag> ah, pablodav is joining us through the Wiki link ;-)
20:58:04 <nitzmahone> Globs aren't supported either way (not sure if dag saw my comments on that PR)
20:58:14 <dag> nitzmahone: ah, I misread that
20:58:29 <nitzmahone> The only wildcards it appears that Test-Path understands with -IsValid are the [a-z] kind
20:58:49 <jborean93> I think it is a lot of work to redo all the modules when we have something that works right now
20:58:50 <dag> nitzmahone: I am not talking about -IsValid (not sure if you read my reply to your comment ;-))
20:59:02 <jborean93> unless there is an issue we are coming across right now
21:00:10 <dag> jborean93: the issue is that most of the modules will fail now if you add a glob-path
21:00:56 <jborean93> wouldn't that be handled with Get-AnsibleParam
21:01:05 <jborean93> instead of changing all our modules
21:03:03 * jhawkesworth_ trying to think where glob paths would have utility.
21:03:16 <nitzmahone> win_robocopy comes to mind
21:03:17 <dag> jborean93: possibly, but then globs are not allowed anywhere
21:03:19 <jhawkesworth_> win_find perhaps.
21:03:36 <jborean93> win_find already has functionality outside of globs to find files
21:03:39 <dag> jborean93: so if we want to go that way, we have to allow for a second type to allow globs
21:05:05 <dag> nitzmahone: Did you see my win_get_url PR ? It fixes the issue we had yesterday
21:05:19 * nitzmahone hasn't looked at it yet, but yeah
21:07:13 <dag> ok, so any decision, or shall we defer ?
21:07:29 <dag> maybe we should get a better impact/scope for the issue
21:07:31 <jborean93> +1 on defer
21:07:36 <jhawkesworth_> I'm tempted to leave as is.  could add a globpath later if needed
21:08:02 <jhawkesworth_> unless already solved in python world.
21:08:02 <dag> jhawkesworth_: I wouldn't change Add-AnsibleParam, but rather fix it in the modules to ensure that's taken care of correctly
21:08:32 <dag> jhawkesworth_: In python globs are an acceptable path by the argspec
21:08:55 <dag> jhawkesworth_: it's up to the module to handle the input (globs are not automatically expanded either)
21:09:12 <dag> the problem is that in Windows, Test-Path does expand if you use -Path instead of -LiteralPath
21:09:21 <dag> so I think it's a Windows issue we have to fix in the modules
21:09:30 <dag> but let's look at the impact/scope
21:09:44 <dag> we can add integration tests, and fix those failures
21:09:59 <jhawkesworth_> makes sense to me
21:10:12 <jborean93> yep let's look at the impact more
21:10:40 <dag> And then we can document the modules that do accept globs
21:10:46 <dag> if that's unclear
21:11:14 <dag> #action Look at impact/scope on Windows modules of globs in paths (not using -LiteralPath)
21:11:43 <dag> next topic ?
21:11:54 <jborean93> we are overtime, wary of keeping you guys back
21:12:23 <dag> I prefer to finish it :p
21:12:45 <jhawkesworth_> ok next time then.  like the idea of diagnostic script  could go in examples
21:13:35 <dag> I would prefer to see the diagnostic script as part of the new ConfigureRemotingForAnsible.ps1
21:13:46 <dag> so we have a single tool to configure/status
21:14:11 <dag> with all the necessary options, and something we could distribute like trondhindenes was hinting on
21:15:09 <jborean93> I'm not sure about bundling it together, the purpose I had for this was a read only script that gave supporters and the user warnings/errors about what we know can go wrong
21:16:02 <jhawkesworth_> I suppose if you put it in the same script, you can at least rule out the 'have you run ConfigureRemotingForAnsible' question :-)
21:17:41 <dag> haha
21:17:47 <dag> ok ok ;-)
21:18:03 <dag> but people running that script, and having issues would already have the script
21:18:34 <jborean93> true, well I'll write a sample script but if we are going to be changing the ConfigureRemoting... then I won't merge it in until we know more about that
21:18:46 <jhawkesworth_> maybe just making ConfigureRemotingForAnsible.ps1 spit out the info you want.
21:18:47 <dag> especially if you're templating images in VMware, it's not easy to get something provisioned before you can access it, so for troubleshooting that is a win
21:18:57 <jhawkesworth_> perhaps with a -validate option that doesn't change, just reports
21:19:15 <dag> no, I don't want to modify ConfigureRemotingForAnsible.ps1
21:19:37 <dag> trondhindenes was looking at making a more modular/versatile equivalent
21:19:41 <jhawkesworth_> sure the better version distributed via ps gallery
21:19:46 <dag> yes
21:20:02 <dag> so if we have that diagnosis script now, and later we merge it in, that's fine
21:20:15 <dag> I don't want one thing be held off because another is vaporware
21:20:21 <jhawkesworth_> agreed
21:20:27 <jborean93> ok
21:20:35 <jborean93> #action jborean93 to work on diagnostic script for WinRM
21:20:42 <dag> but I also prefer too look at the end-goal (I am an utopist afterall)
21:21:16 <dag> hmm, reading up on what that means, I am using that wrong ;-)
21:21:41 <jhawkesworth_> idealist, perhaps?
21:21:57 <dag> nah, that's not the same ;-)
21:22:02 <jborean93> final topic
21:22:09 <jborean93> #topic https://github.com/ansible/community/issues/153#issuecomment-314325343 SID utils
21:22:34 <jborean93> basically it balls down to whether we want to support service accounts like SYSTEM without specifying NT AUTHORITY\ in the beginning
21:22:49 <jhawkesworth_> I'd like be able to use SYSTEM and NETWORK SERVICE without the NT AUTHORITY guff
21:23:06 <jhawkesworth_> feels more user friendly
21:23:20 <jborean93> I feel we have modules that support that already as well
21:23:44 <jhawkesworth_> then they could use common code eventually without interface change
21:23:48 <nitzmahone> And anyone that's managed to name domain accounts with those names deserves what they get
21:24:10 <jborean93> I just tried it now and SYSTEM is a reserved name
21:24:13 <jborean93> not sure on the others
21:25:04 <nitzmahone> I think most things are pretty good about not letting you choose those as names for domain objects
21:25:22 <nitzmahone> (so like I said, if you managed to do that, you're on your own ;) )
21:25:34 <jborean93> either way if they have issues they can still just specify DOMAIN\SYSTEM to get it working
21:25:41 <jborean93> SYSTEM would just favour the local NT AUTHORITY object
21:25:53 <jborean93> but god save them if they come to that
21:26:10 <jborean93> sounds good
21:26:28 <dag> +1
21:26:30 <jborean93> looks like we want to be able to specify NT AUTHORITY\* objects without the prefix in SID lookups
21:26:40 <jhawkesworth_> +1
21:26:48 <nitzmahone> Yep- it's a well-known list
21:26:55 <dag> I assume you guys know what you're doing ;-)
21:27:06 <jborean93> ok unless someone has anything else pressing I'll draw this meeting to a close
21:27:22 <dag> well, lot's of open PR's ;-)
21:27:46 <dag> and a lot of new modules too
21:27:59 <jborean93> yep some are waiting on people to make changes, others for review
21:28:00 <jhawkesworth_> have working mobile data again as of today, will start tackling again tomorrow
21:28:03 <nitzmahone> We should do a press on some of that stuff before we get too close to freeze
21:28:15 <dag> nitzmahone: +1
21:28:27 <dag> some are looking quite good
21:28:31 <nitzmahone> I hate trying to clear a bunch of that stuff hours before freeze. ;)
21:28:50 <dag> and we also have a bunch of integration tests to write :-/
21:28:54 <nitzmahone> More eyeballs looking is always good- thankful for all y'all!
21:29:07 <nitzmahone> Those can definitely happen after freeze though
21:29:09 <dag> do we have a view on when the Windows infra is going to be faster ?
21:29:52 <nitzmahone> I wouldn't expect any changes during 2.4 timeframe. We're looking at internal RH datacenter resources that would allow us to spin up more Windows stuff faster and cheaper, but it's a slog
21:30:06 <dag> nitzmahone: tests always improved the quality of the modules, so I'd prefer not to postpone...
21:30:23 <dag> but resources...
21:30:40 <dag> jhawkesworth_: when do we do the next sprint ?
21:30:47 <nitzmahone> Sure, I'm just saying I'd prefer to get modules merged before freeze even if they're missing tests (we can be filling in tests after freeze)
21:31:04 <nitzmahone> as opposed to front-loading test writing and potentially missing out on modules for 2.4
21:31:36 <dag> right
21:31:38 <jhawkesworth_> how about next week for another sprint?
21:31:41 <dag> agreed
21:32:39 <dag> jhawkesworth_: maybe next week is going to be hard, need to check
21:32:51 <dag> week after we are on vacation for 2 weeks
21:34:42 <jborean93> I'll let you guys organise that, got to head off for some breakfast
21:34:45 <jhawkesworth_> we are going to be getting into a popular time for vacation
21:34:50 <jborean93> #endmeeting