20:00:37 <nitzmahone> #startmeeting Windows Working Group
20:00:37 <zodbot> Meeting started Tue Sep 12 20:00:37 2017 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:37 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:52 <jhawkesworth_> hello
20:00:56 <nitzmahone> #info agenda https://github.com/ansible/community/issues/195
20:01:01 <nitzmahone> Hey Jon!
20:01:32 <jborean93> hey
20:01:33 <jhawkesworth_> heya.
20:01:59 <nitzmahone> #chair jborean93 jhawkesworth_
20:01:59 <zodbot> Current chairs: jborean93 jhawkesworth_ nitzmahone
20:02:34 <nitzmahone> I don't see dag on right now, so I guess we can get started
20:02:57 <nitzmahone> 2.4 is at rc2- rc3 will likely be cut tomorrow
20:03:21 <jborean93> #topic diff name https://github.com/jborean93
20:03:34 <jhawkesworth_> will try and do some testing.  feeling more confident though as more test coverage than before.
20:04:07 <jborean93> god my IRC is off
20:04:12 <nitzmahone> lol
20:04:33 <jhawkesworth_> I was wondering why the link to your ghub ?
20:04:34 <nitzmahone> Assume you're talking about https://github.com/ansible/community/issues/195
20:04:45 <nitzmahone> dammit https://github.com/ansible/community/issues/195#issuecomment-320536103
20:04:55 <nitzmahone> It's the comedy of errors today
20:05:12 <jborean93> haha yep
20:05:20 <jborean93> just wanted to see if people prefered diff or diff_mode
20:05:32 <nitzmahone> Until we've got the new thing, I'd vote for $diff_mode
20:05:36 <jhawkesworth_> diff_mode works for me
20:05:51 <jborean93> same, looks like that is the choice
20:06:01 <jborean93> dag was against it as it was technically not a mode like check mode
20:06:39 <nitzmahone> For better or worse, that's what the core feature is called, and the module doesn't *need* to collect that data if it's not enabled, so it really is a separate "mode" IMO
20:07:00 <nitzmahone> <bikeshed/>
20:07:06 <jhawkesworth_> feels like a different mode to me - changes behaviour.
20:07:12 <jborean93> cool, that's sounds good to me
20:07:15 <jborean93> I'll update the ticket
20:07:32 <jhawkesworth_> maybe I don't understand where dag was coming from regarding that.
20:07:46 <jhawkesworth_> but if its $diff_mode everywhere, easy enough to change later
20:08:05 <jborean93> it's a mix
20:08:12 <jborean93> I use $diff_mode, he does $diff
20:08:53 <nitzmahone> Both are clear enough IMO- consistency is nice (especially if we ever decide to "cut over" to the new thing whenever I merge it)
20:09:30 <jborean93> I might skip over dag's agenda item as he would be best to talk about it
20:09:36 <nitzmahone> agreed
20:09:43 <jhawkesworth_> curious what new thing is if that's not too much of a tangent.  agree either is clear enough but prefer consistency
20:10:07 <jborean93> is this the new module api in .net?
20:10:10 <nitzmahone> Just the C# arg validator stuff I've been messing with
20:10:12 <nitzmahone> yeah
20:10:31 <nitzmahone> Core stuff keeps getting new features added to it that I haven't gone back and patched in yet
20:10:35 <jborean93> is that planning on throwing errors/warnings on invalid args?
20:10:43 <nitzmahone> Yeah
20:11:00 <jborean93> cool, I saw a comment about that recently
20:11:09 <nitzmahone> That's the way it works ATM, though I've also played with a couple of event-based ways to do it too
20:11:42 <jborean93> looking forward to seeing it :)
20:11:51 <jborean93> anything else on that before we move on?
20:11:58 <nitzmahone> The hard part is getting a managed exit to work the same way from a C# app and a PS script
20:12:11 <nitzmahone> Nah
20:12:21 <nitzmahone> #topic https://github.com/ansible/community/issues/195#issuecomment-328660671
20:12:40 <nitzmahone> So there are a couple ways we could fix https://github.com/ansible/ansible/issues/23019
20:13:14 <nitzmahone> Jordan did some testing and turns out the sanest way is probably to just switch win_shell/win_command over to using CreateProcess instead of Process.Start()
20:13:45 <nitzmahone> I'd like to just fix it on the main cmdline, but it's technically a breaking change
20:14:08 <nitzmahone> (for anyone who's figured out the escaping hoops to jump through to do special spacing)
20:14:14 <jborean93> the only trouble is that we "may" have issue with people that have already doubly escaped the argument quotes
20:14:32 <jhawkesworth_> I think if we are clear about what they have to change in the migration guide this is ok
20:14:54 <jhawkesworth_> I trawled through all of my roles and playbooks when moving to 2.3 to get rid of 'raw'.
20:15:06 <nitzmahone> I think I'd rather break those few cases that might be out there and have it work "as expected" for anyone coming new to it than have a weird compat mode or different args to get the "proper" behavior.
20:15:16 <jborean93> it also makes it more representative of what Windows actually accepts instead of our extra overlay on top
20:15:21 <jborean93> yep I agree
20:15:22 <nitzmahone> indeed
20:15:29 <jhawkesworth_> I wound up using win_shell almost everywhere because win_command could only handle the simplest command lines.
20:15:41 <nitzmahone> This *should* fix thiat
20:16:06 <jborean93> The other benefit is that we can introduce the stdin argument for 2.5 to have feature parity with shell/command
20:16:14 <nitzmahone> So sounds like we're all on the same page- we'll plan to get that in for rc3 then
20:16:30 <nitzmahone> and yeah, that'll be a nice bonus
20:16:44 <jhawkesworth_> definitely if we can get stdin that would be a great bonus
20:17:14 <nitzmahone> #agreed breaking change to cmdline parsing for win_shell/win_command for 2.4, ensure it's documented
20:17:24 <jborean93> #topic https://github.com/ansible/ansible/pull/28995
20:17:35 <jhawkesworth_> gundalow will thank for adding to the migration guide too
20:17:54 <jborean93> was hoping to get some people looking at the win_scheduled_task PR when they get a chance
20:18:07 <gundalow> jhawkesworth_: nps, need more love for 2.4 though
20:18:34 <jborean93> it's a pretty big change and is making me question whether we should split into separate modules or create a separate one and deprecate win_scheduled_task in the future
20:18:36 <nitzmahone> I can't remember- are you already doing the "blow everything away on changes" behavior, or are you trying to mutate the individual objects?
20:18:46 <jborean93> individual objects
20:18:57 <nitzmahone> Yeah, that definitely makes it a lot hairier
20:19:07 <jborean93> so it is theoretically idempotent on individual settings
20:19:47 <jborean93> even if you delete a task, if you create one with the same name that was deleted I believe the history is kept
20:20:08 <nitzmahone> Yeah, which is why I wonder if we're gilding the lily a bit with the idempotence
20:20:25 <jborean93> you would need to know that a change has occured
20:20:35 <jhawkesworth_> if it could be 'functionally idempotent' maybe there could be less code
20:20:42 <jborean93> it's pretty simple to make it, there is just a lot of options
20:20:46 <nitzmahone> If we don't worry about shared triggers or anything, it's just detection + deletion + creation (no mutation)
20:21:07 <nitzmahone> Dunno how much code that gets rid of though without really digging in
20:21:22 <jborean93> I don't think too much
20:22:02 <nitzmahone> So my personal red flags for "this should be multiple modules" are:
20:22:16 <nitzmahone> - large code size (check)
20:22:41 <nitzmahone> - potential for significantly larger code size in the future to accommodate new features (unlikely)
20:22:56 <nitzmahone> - multiple underlying resources (check)
20:23:16 <nitzmahone> - complex interaction between those resources (doesn't feel like it)
20:23:24 <jborean93> It would still just be one resource, just multiple attributes of the one resource
20:23:25 <nitzmahone> So this would definitely be on the bubble for me
20:24:10 <jborean93> for the 2nd, I tried implementing as many options as possible but there are 1 or 2 things that aren't there because they are a bit more complex
20:24:39 <jhawkesworth_> I don't have any useful experience of scheduled tasks so can't comment from user perspective on this one.
20:25:03 <jborean93> I don't really want to split them as it would mean someone would need multiple tasks to create a scheduled task
20:25:14 <nitzmahone> From a user perspective, I think I'd be put-off by this if it were multiple modules
20:25:19 <nitzmahone> mental jinx
20:25:50 <nitzmahone> I'm +1 for leave it as one
20:26:27 <jhawkesworth_> not obvious how you could slice it to me and still have 'simple things are easy and hard things are possible;
20:26:38 <nitzmahone> We may want to factor some of this stuff out into shared code anyway if we end up doing a scheduled-task become methods.
20:26:39 <jborean93> ok, I'll continue as is and start creating more tests before removing the WIP
20:27:06 <jborean93> I tried reducing code duplication as much as possible but there is a good chunk around handling deprecated args as well
20:27:17 <jborean93> plus argument validation to fail at the beginning instead of the end
20:28:18 <nitzmahone> On to https://github.com/ansible/community/issues/195#issuecomment-328967548
20:28:21 <nitzmahone> #topic https://github.com/ansible/community/issues/195#issuecomment-328967548
20:28:32 * jborean93 was too slow
20:28:49 <nitzmahone> Oh, did you have more on that?
20:29:02 <jborean93> haha no, was just typing the next topic
20:29:06 <nitzmahone> ah ok
20:29:19 <jhawkesworth_> so yeah just clearing up my PRs and had this idea of a facts module that just tells you about installed stuff.
20:29:28 <nitzmahone> So I'd be for win_hotfix_facts and win_package_facts module
20:29:37 <jborean93> I've got no issues with that
20:29:49 <jhawkesworth_> oh ok, even more granular then.
20:29:56 <nitzmahone> Dunno if there's really a benefit to combining them, since the "shape" of those things would be different
20:30:01 <jborean93> I see win_package_facts being useful for people trying to get product ids
20:30:09 <nitzmahone> yeah
20:30:26 <jhawkesworth_> ok.
20:30:42 <nitzmahone> win_hotfix_facts could probably just be a simple wrapper over Get-Hotfix
20:31:01 <jhawkesworth_> yeah it would be just a handful of lines of code .
20:31:11 <jborean93> simple is better
20:31:18 <jhawkesworth_> I saw some items about facts refactoring on the contributor summit agenda.  Does anyone know if that got discussed?
20:31:41 <nitzmahone> I don't think we really discussed that much, at least not in the big session
20:31:49 <nitzmahone> One of the breakouts might have
20:32:09 <jhawkesworth_> ok.  doesn't hugely matter as win_hotfix_facts and win_package-facts would be little things and easy to shift around I guess.
20:32:19 <jhawkesworth_> well I'll plow on with that idea then.
20:32:31 <dag> o/
20:32:33 <jhawkesworth_> hey dag
20:32:37 <dag> meeting still ongoing ?
20:32:43 <nitzmahone> yep
20:32:51 <nitzmahone> we just hit the end of the agenda (sans your items)
20:33:24 <dag> school stuff, first meeting with classroom/teacher of youngest
20:33:32 <nitzmahone> good times
20:33:46 <dag> my item is very simple
20:34:02 <dag> not much to it, (well, you have the implementation that may suck)
20:34:38 <dag> and the discussion between reboot_required vs ansible_reboot_pending
20:34:40 <nitzmahone> I generally don't mind the idea- if it's implemented to use a shared check
20:35:06 <nitzmahone> What would be bad news is if module a and module b both update that with different impls.
20:35:15 <dag> nitzmahone: right, but if you want to use a shared check (shared code) we need a solution for that in the facts framework
20:35:38 <nitzmahone> What's wrong with just having it in module_utils?
20:35:48 <dag> (which is one facet of my holistic facts design topic I think we need in the core team)
20:36:13 <dag> nitzmahone: that's a possibility, but would be custom for these shared facts
20:36:15 <nitzmahone> It's a single fact value to be updated instead of a big pile
20:36:36 <nitzmahone> So facts that we want to support that for would need to be individually callable
20:36:45 <dag> we might as well design the facts-systems so that every fact (or collection of facts) could be updated
20:36:48 <dag> right
20:37:12 <dag> but there's another open topic of being able to more fine-grained facts updating
20:37:35 <jborean93> We could theoretically update groups together that use the same source
20:37:38 <dag> (or at least, being able to update collections of facts pertaining a certain topic)
20:37:47 <dag> right
20:38:00 <jhawkesworth_> hmm, might wind up with a rather slow setup module if lots of dindividual calls to get facts.
20:38:04 <nitzmahone> So we *sorta* already have that with gather_subset, though we haven't implemented that on Windows yet
20:38:23 <dag> nitzmahone: exactly, and that's only related to facts
20:38:42 <dag> my holistic facts topic really wants to look at everything related to facts, also _facts modules etc...
20:38:56 <nitzmahone> I like the purity of individually callable facts, but I suspect it would be a performance problem without some careful lazy-init/caching
20:39:11 <nitzmahone> Totally do-able, just a big change
20:39:16 <dag> indeed
20:39:53 * dag also want a plugin facts system, where people can hook into the father_facts mechanism for specific stuff they need that is very custom
20:40:16 <dag> I had a few customers that needed something like that (rather than a custom facts module they have to run from various places)
20:40:17 <nitzmahone> But yeah, I wouldn't want to widely embrace a pattern like this *without* also providing a way to ask for a known impl for a given fact (rather than leaving each module to recalculate it by itself, because that would be a disaster in the making)
20:40:25 <jhawkesworth_> i did wonder if roles could require facts / classes of fact which would get determined as playbook is parsed
20:40:51 <nitzmahone> That's getting harder as we make playbooks/roles more dynamic
20:41:02 <dag> nitzmahone: the implementation for Windows could be quite simple at this point since we don't have a lot of legacy, we simply have to make sure what we do is vetted by core IMO
20:41:18 <nitzmahone> 1.9-ish that was really easy, but with the per-host tasklist from 2.0 and all the dynamic roles stuff, it's nearly impossible now
20:41:30 <dag> yup
20:42:11 <dag> jhawkesworth_: there's no problem though to have roles ship with their own facts modules in that case, as it's pretty contained
20:42:33 <dag> the need at customers really is to ensure basic facts exist that are used everywhere throughout playbooks
20:42:34 <nitzmahone> So another way we could do that is to have a little framework for that and only move the tasks that need the kind of "dynamic recalculation" into it as needed
20:42:48 <dag> (but these basic facts are very custom in nature totheir setup)
20:42:49 <jhawkesworth_> yeah, maybe just diminishing returns to have roles have some meta so they can request certain facts
20:43:22 <dag> jhawkesworth_: I think we need to consider it for that holistic facts approach
20:43:31 <nitzmahone> jhawkesworth_: yeah, if a role author didn't mind predeclaring the list of facts in role meta, you could do it that way
20:43:55 <jhawkesworth_> jeff geerling might not thank me with all his galaxy roles :-)
20:44:07 <dag> nitzmahone: so what to do with the existing PR ?
20:44:08 <nitzmahone> Could also do it with a wildcard approach
20:45:24 <nitzmahone> There's nothing to stop someone from doing this already, but I'm not sure we want to open that particular Pandora's box without the ability to call a shared impl
20:45:45 <jhawkesworth_> coming up with fact classes, and figuring out what would be in and out of each fact class sounds like a non trivial piece of work
20:47:12 <dag> I guess I have to start collecting everything related to facts, and ideas and write that proposal, although I don't feel confident having all wisdom though
20:47:39 <nitzmahone> You don't need to have all wisdom, but a strawman is a good thing to start from
20:47:56 <dag> and then bcoca comes along and kills all hope :-D
20:48:01 <nitzmahone> lol
20:48:05 <jhawkesworth_> been there!
20:48:10 <dag> been there ;-)
20:48:42 <jhawkesworth_> never mind I will just use awx to get parallel playbook execution now :-)
20:48:51 <dag> ok, I guess we could already start identifying the different modules that could update facts and put it on the progress page
20:48:52 <nitzmahone> There are already likely to be some large user-visible architectural changes coming in 2.5, so I don't know if we'd get to actually building this for 2.5
20:49:18 <dag> nitzmahone: it's not Windows-specific, I'll take this up to core team
20:49:30 <nitzmahone> Definitely got some ideas swirling though on how we could do this and make it pluggable (and meet some of dag's other wishes for it)
20:49:31 <dag> but in my opinion this is part of the new facts napespacing thing
20:49:40 <dag> namespacing
20:49:42 <nitzmahone> agreed
20:50:17 <dag> anyway, any other stuff to discuss ?
20:50:37 <dag> Sprints ? Progress ? What's Jordan up to ? etc... :-)
20:50:43 <jborean93> I'm good, only a few things left to do for 2.4
20:50:53 <dag> you have been very active
20:50:56 <dag> it's scary
20:51:10 <jborean93> giving you a run for your money :)
20:51:11 <nitzmahone> Just that dag's a ballsy dude to rely on around-the-world machines being up and accessible during a live conference talk.
20:51:23 <nitzmahone> :D
20:51:25 <dag> I think we can close shop after v2.5 if this goes on :-D
20:51:36 <jhawkesworth_> :-)
20:51:59 <dag> nitzmahone: I knew things wouldn't work smoothly, it's an elementary school :-)
20:52:23 <nitzmahone> The lady sitting next to me leaned over afterwards and was like, "so, does Ansible work on servers too?"
20:52:37 <dag> haha, no way :-)
20:52:40 <jborean93> haha, just iPhones
20:52:41 <nitzmahone> srsly
20:52:46 <jhawkesworth_> looking forward to the video
20:53:08 <nitzmahone> I think I'm gonna punt 21915
20:53:16 <nitzmahone> https://github.com/ansible/ansible/issues/21915
20:53:22 <dag> well, I got quite a lot of people asking questions after the talk, while I thought this was more like a niche thing (desktops)
20:53:45 <jborean93> there is a workaround for 21915
20:53:50 <jborean93> just not very nice
20:53:57 <jhawkesworth_> the chcp thing?
20:54:00 <nitzmahone> yeah
20:54:21 <jhawkesworth_> document it and be done.  Get off s2008 already!
20:54:26 * dag wanted to change keyboard settings the right way in Powershell, but it requires an interactive shell wft !
20:54:29 <nitzmahone> Might be something I can address in the new platform plugin too, but no sane way to do it for current code
20:54:34 <jborean93> I tested it out here https://groups.google.com/forum/#!topic/ansible-project/dV6fIfIdk-Y
20:54:46 <jborean93> but nitzmahone probably has a better solution
20:55:40 <nitzmahone> It's hard to do without adding first-class support for arbitrary codepages, which I *really* don't want to do
20:55:43 <nitzmahone> UTF8 4eva!
20:55:57 * jhawkesworth_ way too much stuff requires interactive shell
20:56:27 <jborean93> Become does an interactive logon now
20:56:56 <dag> jborean93: ah ? really
20:57:01 * nitzmahone needs to go back and play with passwordless become again
20:57:04 <dag> I'll check right away
20:57:19 <dag> this should be documented :)
20:57:24 <dag> (or maybe it is)
20:57:53 <nitzmahone> It's not yet. I feel *better* about the stability of become/runas in 2.4 than I did in 2.3, since at least the kerb/ntlm stuff works now
20:59:11 <nitzmahone> I'm also going to punt 18108- doing that one right will also rely on either the platform abstraction or fact refreshing
20:59:52 <nitzmahone> 23109 should be fixed today https://github.com/ansible/ansible/issues/23019
20:59:52 <dag> jhawkesworth_: how about another sprint ? what would you prefer ?
21:00:26 * dag has tagged a few migrated issues with windows (as ansibot did not pick up the old stuff)
21:00:34 <nitzmahone> yeah, saw that- thanks!
21:00:42 <dag> is:issue is:open windows -label:windows
21:00:54 * nitzmahone suspected that's what you did
21:00:57 <jborean93> yep, was thinking yesterday why I hadn't seen them before then realised you recently tagged them, thanks for that
21:02:04 <jborean93> nothing else before we end the meeting?
21:02:12 <jhawkesworth_> yeah I'd like to do another sprint.  I'm having a go at some 'next steps' for window documentation at the moment but could do next week.
21:02:26 <dag> when is v2.4 due ?
21:02:38 <nitzmahone> Next week
21:02:52 <dag> maybe after v2.4 release then
21:02:58 <nitzmahone> After tomorrow, we're only merging regression fixes
21:02:58 <jhawkesworth_> makes sense
21:03:08 <dag> we'll plan next week
21:03:09 <nitzmahone> (to stable-2.4)
21:03:45 <jhawkesworth_> documentation stuff I have in mind is not release specific.
21:04:14 <dag> ah, we didn't merge the path stuff in v2.4 :-/
21:04:22 <nitzmahone> which?
21:04:35 <dag> it's been mostly written for months now, but unmerged
21:05:07 <dag> https://github.com/ansible/community/wiki/Windows%3A-documentation and https://github.com/ansible/community/wiki/Windows-Paths---prescriptive-style
21:05:59 <nitzmahone> We can take docs stuff anytime, too- doesn't have to be tied to a release
21:06:17 <jhawkesworth_> happy to add the paths stuff in to my PR when I get to it.
21:06:18 <nitzmahone> (well, now that we're doing versioned docs, it's a little trickier, but still)
21:07:59 <nitzmahone> OK, done for the day?
21:08:53 <jborean93> I'm good
21:08:55 <jhawkesworth_> yeah I'm done - need sleep!
21:09:01 <nitzmahone> Thanks all!
21:09:05 <nitzmahone> #endmeeting