20:00:11 <nitzmahone> #startmeeting Windows Working Group
20:00:11 <zodbot> Meeting started Tue Aug 29 20:00:11 2017 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:11 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:17 <nitzmahone> #info agenda: https://github.com/ansible/community/issues/195
20:00:39 <jborean93> Morning
20:00:51 <nitzmahone> How's the jetlag?
20:01:14 <jborean93> TBH hasn't kicked in which I'm grateful for
20:01:31 <jborean93> I had an ok sleep in the LA to Brisbane flight which helped a lot
20:01:36 <nitzmahone> Nice. I was waking up at 4:30am the first couple days back, seem to have kicked that
20:01:53 <jhawkesworth_> hey
20:01:58 <nitzmahone> sup!
20:02:11 <jborean93> hey
20:02:46 <dag1> o/
20:03:04 <nitzmahone> #chair jborean93 dag1 jhawkesworth_
20:03:04 <zodbot> Current chairs: dag1 jborean93 jhawkesworth_ nitzmahone
20:03:41 <jborean93> A full house, has been a while
20:03:49 <dag1> jborean93: I made some new PRs to win_chocolatey and win_get_url
20:03:55 <nitzmahone> So it's freeze day... I'm doing a bunch of Azure stuff this afternoon, and planning to merge 28448.
20:04:19 <jhawkesworth_> 28448 being dag's win_reboot changes
20:04:22 <jhawkesworth_> cool
20:04:29 <jborean93> dag1: I have seen them, just going over all my notifications this morning
20:04:34 <dag1> ok
20:04:57 <jborean93> If I get to the win_chocolatey one you will probably have to rebase as I plan to merge those older ones before hand
20:05:14 <nitzmahone> Yeah- it's still not ideal, but until Microsoft lets slip the secret system object to monitor that tells us we're not applying updates, the post_reboot delay may be a necessity for some people. :(
20:06:15 <dag1> jborean93: no problem, it's a heavy one but will help with debugging issues
20:06:39 <jborean93> I've been planning on looking at win_chocolatey to change the way it runs processes but that is a 2.5 thing for me
20:06:47 <dag1> jborean93: the proxy one will require 0.10.4 which allows me to clean up some other parts
20:07:00 <dag1> jborean93: ah, that's what I just did
20:07:18 <jborean93> ok will have a look
20:07:24 <dag1> Getting rid of Invoke-Expression
20:07:30 <nitzmahone> +1000 to that
20:07:33 * jborean93 shudders
20:07:39 <jhawkesworth_> hear hear!
20:07:52 <nitzmahone> Oh, on another front:
20:07:57 <dag1> it fails on parsing the docs, will fix that first
20:08:09 <nitzmahone> I have a working ansible-test plugin for PSScriptAnalyzer
20:08:14 * dag1 plans to work through the night in order to get everything merged before the freeze
20:08:34 <dag1> w00p !
20:08:37 <nitzmahone> It currently requires docker, though
20:09:21 <nitzmahone> I can extend it in the future to work with a locally-installed one if you have it, but the current impl won't work under WSL because of the docker req (I think- haven't tried docker against a VM under WSL)
20:09:46 <jborean93> better than nothing, as long as we document how people can run it manually I think we will be fine
20:10:10 <jhawkesworth_> yep, no experience of docker but if there's a way to run locally, that would be great
20:10:10 <nitzmahone> It'll be similar to pep8 where we'll have both a  skiplist and an ignore list (and it'll fail on the "doesn't need to be ignored anymore" case as well like pep8 does)
20:10:42 <nitzmahone> I don't anticipate needing the skiplist for anything, but better safe than sorry
20:11:50 <nitzmahone> I'll try to get that hooked up in CI soon, but it might not happen before 'fest
20:11:57 * dag1 plans to fix everything under the sun
20:12:47 <nitzmahone> Any other known module/feature PRs we want to try and sneak in under the wire?
20:13:04 <jhawkesworth_> just looking here: https://github.com/ansible/ansible/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20label%3Awindows
20:13:22 <jhawkesworth_> .. for things with 'Approved' on
20:13:42 <jborean93> nitzmahone: I've got a few I'm planning on putting through
20:13:48 <jborean93> just need to test them after some changes
20:13:59 <dag1> win_firewall_rule
20:14:11 <dag1> the current module has quite some issues (non-idempotent)
20:14:21 <jborean93> My only objections to that is it removed the original return values
20:14:22 <nitzmahone> OK. McKerr wants to send out the final freeze notification today ~ end of day ET if possible
20:14:37 <jborean93> They aren't documented right now and it is preview so happy to merge
20:14:40 <jborean93> just wanted to get a consensus
20:14:42 <dag1> jborean93: are they hard to add again ?
20:14:57 <jborean93> Not sure, the implementation has changed from how it originally got the values I believe
20:15:15 <nitzmahone> IIRC they were a little weird anyway
20:15:23 <dag1> the win_toast is ready to be merged too
20:15:27 <nitzmahone> Since it's preview, I'd vote to leave out and see if anyone complains
20:15:45 <jborean93> ok will merge the win_firewall_rule, looks like a decent change from before
20:15:52 <dag1> ah wait, jhawkesworth_ it was decided not to add units to parameter names
20:15:53 <jborean93> For win_toast do we need to run it with async?
20:15:54 <nitzmahone> It's not a fact-y module, so utility of those return values is iffy anyway
20:16:29 <nitzmahone> I'd rather not merge win_toast if that's the case
20:16:47 <nitzmahone> We can hide the async-ness in the module directly
20:17:05 <dag1> it's sad win_certificate is not ready :-/
20:17:35 <jhawkesworth_> win_toast will run without async (the integration test does this)
20:17:43 <nitzmahone> ok cool
20:18:01 <jhawkesworth_> its just slow if you do as it sleeps for expires_seconds
20:18:12 <dag1> ah, the win_pagefile author wants his module in as well, he's been ready for quite some time
20:18:41 <jborean93> I'm about to press the merge for win_power_plan right now
20:18:46 <jborean93> just waiting for the tests to pass
20:19:04 * jborean93 just merged win_firewall_rule
20:19:10 <jhawkesworth_> I can take out units - looks like the 'echoed' input params need to go as well?
20:19:30 <dag1> ok, I will test win_firewall_rule right away in his setup
20:19:37 <dag1> jhawkesworth_: yes
20:19:53 <dag1> it seems to be a practice frequented more in the Windows modules
20:20:12 <dag1> jborean93: let me know when I need to rebase my win_chocolatey stuff
20:20:16 <jhawkesworth_> I think both nitzmahone and I like units in module parameters
20:20:27 <nitzmahone> We were just discussing today in core mtg
20:20:29 * jborean93 am ambivalent
20:20:41 <dag1> jhawkesworth_: in v2.5 we will introduce 2 new data types: datetime and duration
20:21:02 <dag1> jhawkesworth_: so in the future one could specify 5mins or 2hours
20:21:16 <jhawkesworth_> nice
20:21:20 <nitzmahone> I'm less sold on datetime BTW- parsing nightmares abound
20:21:26 <jborean93> For the win_chocolatey stuff, currently the author sets the proxy info in a config file. I prefer to use the explicit exe parameters but they were only added in a recent version. Happy to use that instead and just add a note to the documentation?
20:21:34 <dag1> nitzmahone: right, most modules need duration anyway
20:21:37 <nitzmahone> But yeah, duration will solve all those problems and we can stay unitless in the arg names
20:22:14 <nitzmahone> Does win_chocolatey have the ability for the module to upgrade choco itself to a minimum version?
20:22:38 <dag1> nitzmahone: we need to have that IMO, it now only installs, so we can lock the user out of chocolatey :-/
20:22:46 <nitzmahone> yep
20:22:48 <jborean93> I believe it does
20:22:55 <dag1> we should have at least a special handling of the chocolatey package (if needed)
20:22:56 <jborean93> I remember seeing a Choco-Upgrade call after the install
20:23:15 <dag1> jborean93: I thought that was only fired when it wasn't already installed
20:23:16 <dag1> hmm
20:23:24 <jborean93> It installs if it isn't
20:23:30 <jborean93> I swear if it finds the exe it upgrades
20:23:36 * jborean93 could be wrong
20:23:38 <nitzmahone> Been awhile since I looked, but I don't remember seeing an internal min version upgrade
20:23:44 <dag1> jborean93: you are right
20:24:02 <jborean93> I'm not a fan of that behaviour personally
20:24:12 <nitzmahone> Which- the silent choco upgrade?
20:24:31 <dag1> only when it is older than 0.9.9 :-)
20:24:34 <jborean93> Both the install if missing and upgrade if present, particuarly the latter
20:24:40 <dag1> and it uses the internal function to upgrade, so that will break
20:24:41 <jborean93> ahh ok not so bad then
20:25:16 <dag1> if the upgrade-part is not longer working for older chocolatey, we need to have a simple upgrade function just for chocolatey
20:25:44 <jborean93> It should just be a requirement for chocolatey to already be installed
20:26:09 <jborean93> Just like we have for things like NSSM, AD modules and the like
20:26:29 <nitzmahone> Did the choco install/upgrade ever get fenced by check mode? It didn't used to
20:26:30 <jborean93> but that's getting away from my question around the proxy stuff
20:26:40 <dag1> jborean93: agreed, but being able to bootstrap makes it so easy :)
20:26:56 <nitzmahone> So long as we provide a useful error if you try to specify something not supported, I'm OK with it
20:27:15 <nitzmahone> I like the self-bootstrapping, but it should respect check mode
20:27:19 <dag1> nitzmahone: not fenced
20:27:23 <nitzmahone> :(
20:27:37 <dag1> I'll look into that too
20:27:58 <dag1> just noticed that the module was adapted for working with chocolatey installs in non-standard locations
20:28:08 <dag1> but not for upgrading chocolatey itself
20:28:24 <jborean93> Ok cool, will merge the guy's PR as is and fix it myself. Will add a version check and state the current chocolatey version doesn't support proxy settings
20:30:06 <dag1> is there anything else we need to do for v2.4
20:30:19 <dag1> like documentation etc...
20:30:22 <nitzmahone> We'll have a few weeks for stabilization activities
20:30:36 <dag1> would be nice to know it in advance :-)
20:30:37 <nitzmahone> I need to add docs for become
20:30:48 <dag1> win_dsc is not well-documented
20:30:58 <dag1> and win_oneget was planned for v2.4 too
20:31:00 <jhawkesworth_> I want to document the 'how to construct windows paths' stuff during RCs
20:31:13 <dag1> yes !
20:31:26 <jborean93> win_oneget won't be ready I dont believe
20:31:33 <jborean93> I had a look at that myself and it is quite confusing
20:31:37 <dag1> unfortunately not
20:31:39 <nitzmahone> Just like the underlying provider... :P
20:31:57 <jborean93> Also requires some bootstrapping with Nuget which is difficult with server's not connected to the internet
20:32:16 <jborean93> overall a pretty poor implementation from Microsoft's side
20:32:20 <jborean93> IMO
20:33:32 <nitzmahone> OK, anything else burning?
20:34:17 <jborean93> not from me, itching to test some PR's
20:34:35 <nitzmahone> back to Azure stuff, then
20:34:44 <nitzmahone> See you next week, dag!
20:35:04 <jhawkesworth_> I'll push updated win_toast shortly
20:35:25 <dag1> nitzmahone: yup ! :)
20:35:26 <jhawkesworth_> have a good time.  I like SF a lot
20:35:35 * dag1 still needs to book hotel :-(
20:35:46 <nitzmahone> Ouch, good thing somebody else is footing the bill
20:35:59 <dag1> at the moment not :-)
20:36:06 <nitzmahone> Staying at the Marriott or somewhere else?
20:36:16 <dag1> but Red Hat offered, so I need to do that first and see what they are willing to refund
20:36:28 <dag1> not sure yet
20:36:36 <nitzmahone> Presidential Suite at the St Francis, then!
20:36:36 <dag1> nothing too expensive
20:36:49 <jhawkesworth_> SF - its all expensive!
20:37:02 <dag1> Hilton SFO
20:37:13 <dag1> that's what my colleague from Cisco is doing
20:37:24 <nitzmahone> Awful commute though
20:37:42 <dag1> euh ? it was a few hundred meters from the venue ?
20:37:43 <nitzmahone> SFO->hotel venue is like an hour on the train
20:39:11 <nitzmahone> Must not be SFO Hilton, because SFO is a LONG ride.
20:40:18 <nitzmahone> Meeting next week is TBD, there's been talk of cancelling all due to 'Fest and contributor summit
20:40:34 <nitzmahone> Talk to everyone soon!
20:40:38 <nitzmahone> #endmeeting