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