20:01:46 <jborean93> #startmeeting Ansible Windows Working Group
20:01:46 <zodbot> Meeting started Tue Jan 30 20:01:46 2018 UTC.  The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:46 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:01:55 <nwsparks> hey
20:02:03 <jborean93> hey
20:02:07 <jborean93> #chair nwsparks
20:02:07 <zodbot> Current chairs: jborean93 nwsparks
20:03:02 <jborean93> give it a minute or 2 to see if anyone else will be joining
20:03:10 <nwsparks> ok
20:04:16 <jborean93> #topic https://github.com/ansible/community/issues/294
20:04:34 <jborean93> Looks like it is just us 2 for now
20:04:49 <jborean93> Is there anything you wanted to talk about?
20:06:13 <nwsparks> i dont have anything for today. i've still got those changes pending for win_lineinfile...will try and get to it in the next few days
20:08:11 <dag> o/
20:08:15 <jborean93> hey
20:08:18 <jborean93> #chair dag
20:08:18 <zodbot> Current chairs: dag jborean93 nwsparks
20:08:19 <dag> sorry, lost track of time :-)
20:08:31 <dag> and was waiting for my topic in the core meeting
20:08:38 <nitzmahone> o/
20:08:42 <jborean93> it looks like it just came up
20:08:45 <jborean93> #chair nitzmahone
20:08:45 <zodbot> Current chairs: dag jborean93 nitzmahone nwsparks
20:08:46 <dag> haha
20:08:48 <nitzmahone> Yeah, core meeting running long today
20:09:33 <jborean93> Cool, well we didn't really have anything productive to add to the meeting, now that dag is here he may want to talk about his topics in the agenda but he may be back and forthing with the core meeting
20:10:07 <jborean93> The only thing I had to add is if you are using win_uri it would be great if you could test out https://github.com/ansible/ansible/pull/35487, I had to change a few underlying libraries and would be good to know if hasn't broken anything major
20:12:22 <nwsparks> on the progress tracker should i remove win_iis_webbinding for idempotence? it was added in the changes i made
20:12:38 <jborean93> I believe so
20:12:57 <jborean93> The main egregious errors seem to be gone and we can track further issues with github issues if needed
20:13:04 <nwsparks> ok
20:13:18 <nwsparks> i dont think i use win_uri in any of my stuff but if i get a chance ill mess with it
20:13:44 <jborean93> Same, but there were a lot of issues opened for it and thought it would be good to fix
20:14:15 <jborean93> I know I broke compatibility with a few things regarding return values but it is a preview module so I'm find with that
20:14:37 <nwsparks> yah
20:14:51 <jborean93> just making sure the change from the `Invoke-WebRequest` cmd to the `System.Net.HttpWebRequest` class didn't break anything else
20:17:31 <jborean93> Apart from that I've got nothing else, I'll leave the meeting open to 7 in case the core meeting finishes and the others wanted to talk about something in particular
20:20:20 <dag> jborean93: thanks for the win_uri work, this was very needed
20:20:34 <dag> jborean93: did you look at feature-completeness wrt. uri module ?
20:21:00 <jborean93> It is mostly there, I think a few minor things are missing but I was aiming more for fixing the issues before adding in more features
20:21:18 <dag> I wanted to add Facts-support to existing modules, as the python modules already do it (without specific support in the facts subsystem)
20:21:36 <dag> so if you change the hostname, the hostname fact is updated automagically
20:21:57 <dag> I wish for Windows the same things would happen (and I already have a second PR ready for it)
20:23:07 <jborean93> I do like the idea, am not opposed to it, but the key is in the impl
20:24:19 <nwsparks> are you just using hostname as an example?
20:24:48 <nwsparks> would it make sense to update it after changing it before a reboot takes place?
20:30:32 <dag> nwsparks: hostname for windows is probably less useful, but it's an example ;-)
20:30:53 <dag> fact is that we don't do new facts gathering after a reboot, so ...
20:31:02 <nwsparks> ah gotcha
20:31:13 <dag> that's been discussed before as well
20:31:24 <nwsparks> that might be nice
20:31:33 <dag> but hostname is the except, think updating PATH
20:31:46 <dag> after that, the facts should have an updated PATH too
20:43:23 <dag> my other PR only had a handful of facts to update
20:43:50 <dag> and only the domain-related stuff was a bit more complicated (as not all that information was readily available, so it required to reuse a bit of setup.ps1)
20:44:18 <dag> although you probably want to reboot after those modules anyway too
20:44:47 <dag> so all-in-all I think it touches about 10 modules, mostly related to reboot_pending/reboot_required
20:44:59 <jborean93> I think moving the facts into a module util would make the reuse a lot easier, that way a module could call the same subset of the setup facts and use the same method to gather those facts
20:45:45 <dag> jborean93: I agree, but it's only win_domain_* that requires a single snippet
20:46:23 <dag> jborean93: so waiting to do the Right Thing(tm) incl. python module_utils is going to be a long journey
20:46:37 <nitzmahone> Yep; that was the plan, but I wanted to get the subset/segmentation stuff taken care of first. Making it down to individual facts will make that code quite large
20:46:39 <dag> whereas the python modules just set those (known) facts
20:47:04 <dag> so I would suggest taking the easy road for now
20:47:06 <nitzmahone> So maybe leaving at individual callable subsets would be best
20:47:32 <dag> the fact that we have Set-AnsibleFact will make it super-easy to replace when the time is nigh
20:47:55 <jborean93> yep, so each subset can be called independently which gathers more than 1 fact but not the whole shebang
20:47:56 <dag> plus in most cases you don't need a lookup (as setup does) because the value is a given
20:48:13 <jborean93> let's just hope we don't need to refresh the processor facts
20:48:18 <dag> :-)
20:48:18 <nitzmahone> (have you both looked at the gather_subset stuff on windows setup.ps1?)
20:48:52 <dag> I did
20:49:41 <nitzmahone> I found a whole bunch more setup parity issues in the process- fixed a couple small ones while I was in there, but the rest will have to wait for 2.6
20:49:43 <dag> I still have not made my mind up whether separate facts modules, or gather_subsets, or something else is best
20:50:15 <dag> because I don't think most facts don't belong in setup.py/setup.ps1
20:50:16 <nitzmahone> My plan was to move subset guts into module_utils so they're callable by modules
20:50:23 <dag> -don't
20:50:47 <dag> processor is one such example, why would someone want that by default in his facts ?
20:51:22 <dag> that's already a very niche thing to want for influencing playbook logic...
20:51:33 <dag> architecture fine, but processor info...
20:51:46 <jborean93> because we didn't have separate facts modules at the time + wanted parity with the Pythons etup
20:52:00 <dag> I agree, was talking in general here ;-)
20:52:17 <nitzmahone> agreed; would prefer if we collected only the `min` subset (and even pare that down a bit IMO) by default
20:53:12 <nitzmahone> But that ship has sailed for the most part
20:53:25 <dag> again, next AnsibleFest we need this big holistic facts discussion :-/
20:53:54 <dag> even if we won't do it before v3.0 it'd be nice if we had the plan drafted
20:54:11 <dag> anyway, not for this meeting...
20:54:39 <nitzmahone> yep; I think we're all agreed we could do a lot better/different than we do now, but will be fun to see if we can coalesce on a shared definition of "different"
20:55:06 <dag> hehe
20:55:14 * jborean93 wonders if we will have 3.0 or 2.10 after 2.9
20:55:16 <dag> as long as we vote, things will be fine
20:55:39 * nitzmahone can't tell if dag is being snarky
20:55:52 <dag> hehe
20:56:04 * nitzmahone avoids making mention of 2016 US presidential elections
20:56:33 <dag> do we need to discuss anything before v2.5 ?
20:56:39 <dag> what's still in the pipeline ?
20:56:46 <dag> what could we still be fixing ?
20:56:54 <jborean93> nothing major from me
20:57:06 <nitzmahone> Once community freeze hits, we'll start more aggressively triaging open issues
20:57:08 <dag> win_uri was major :-)
20:57:38 <dag> I was going over the progress page, there's still some meat in there
20:57:57 <nitzmahone> Been trying to get all the feature stuff over the line for Windows and Azure (the latter has been sucking up a lot of time for me this go'round)
20:58:06 <dag> I noticed
20:58:11 <dag> a lot of modules !
20:58:12 <nitzmahone> I didn't get to a lot of Windows stuff :(
20:58:29 <jborean93> Azure has been... fun
20:58:29 <nitzmahone> Thankfully Jordan's been cranking stuff out like a machine ;)
20:58:33 <dag> so jborean joined the team and pushed you out, it seems :-)
20:59:20 <jborean93> ha never, nitzmahone is forever the OG Windows guy
20:59:21 <nitzmahone> More like "saved my a$s" - if this Azure stuff had hit and he wasn't here to do what he's been on Windows, it'd be a pretty quiet release (or I'd be working 20h days)
20:59:24 <dag> jborean93: were you involved in azure as well ?
20:59:46 <jborean93> briefly, been doing some reviews of the PRs and worked on some minor issues
20:59:48 <dag> jborean93: was doing 20h days...
20:59:55 <jborean93> nitzmahone has been doing the bulk of the work there
21:00:01 <nitzmahone> well, technically church and sivel are the real OG Windows guys, but I bet they'd never admit it ;)
21:00:28 <jborean93> so much so they are not a part of this channel
21:00:41 <nitzmahone> deadbeat dads ;)
21:00:43 <dag> hehe
21:02:00 <jborean93> cool, well probably time to close the meeting unless you had more to talk about
21:02:06 <nitzmahone> I'm good
21:02:18 <dag> well, the Windows stuff has very quickly matured the past 2 years, now with pslint
21:02:29 <dag> and maybe style-related checks ?
21:02:34 <pablodav[m]> Hello
21:02:42 <jborean93> #endmeeting