20:00:01 <nitzmahone> #startmeeting Windows Working Group
20:00:01 <zodbot> Meeting started Tue Oct 17 20:00:01 2017 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:01 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:09 <nitzmahone> #info agenda: https://github.com/ansible/community/issues/195
20:00:21 <jborean93> morning/afternoon
20:00:30 <nitzmahone> #chair jborean93
20:00:30 <zodbot> Current chairs: jborean93 nitzmahone
20:00:44 <jhawkesworth_> hey
20:00:51 <nitzmahone> Sup Jon?
20:00:58 <nitzmahone> #chair jhawkesworth_
20:00:58 <zodbot> Current chairs: jborean93 jhawkesworth_ nitzmahone
20:02:02 <jhawkesworth_> sorry just getting windows opened / eyes focused
20:02:13 <jborean93> Is that meant to be a pun?
20:02:18 * nitzmahone groans
20:02:44 <jhawkesworth_> doh.  funny without meaning to be.  browser windows.
20:02:59 <dag> o/
20:03:04 <nitzmahone> Hey!
20:03:04 <jborean93> you should have rolled with it :)
20:03:07 <jhawkesworth_> hey dag
20:03:08 <nitzmahone> #chair dag
20:03:08 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitzmahone
20:03:10 <jborean93> hey dag
20:03:14 <jhawkesworth_> :-)
20:04:14 <nitzmahone> Just scrolling through the agenda
20:04:15 <jborean93> well I don't think anyone else is turning up
20:04:19 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-335213640
20:04:46 <nitzmahone> This seems like a major microperf bit for a typical module...
20:05:29 <jborean93> If anything we should probably look at doing it for the exec wrappers
20:05:48 <jborean93> probably won't amount for too much but we gotta squeeze every penny
20:05:52 <jhawkesworth_> that's a good point
20:06:37 <dag> I am wondering, don't we already have a pipe set up, regardless ?
20:06:45 <nitzmahone> Yeah- I'm not opposed to switching our code around to either `$crap = Disregard-Output` or one of the others
20:07:05 <nitzmahone> I think it's more about the use of a pipeline inside the execution
20:07:30 <nitzmahone> If you look down on StackOverflow that's basically the point someone makes
20:07:39 <dag> because when I read that, it felt like there's no real gain if there's already a pipeline set up
20:08:15 <jhawkesworth_> its possible any speed up is insigficant what with all the network / winrm overhead.
20:08:30 <nitzmahone> For most things I suspect that'd be true
20:08:32 <dag> I don't know how we are doing things, but if this is anything related to Linux, there's always a pipeline
20:08:41 <nitzmahone> setup.ps1 would probably be one of the best places to look for it though
20:08:55 <nitzmahone> I think the slowdown comes when you pipe between two cmdlets
20:09:10 <nitzmahone> Not having an output pipeline present
20:09:18 <dag> right
20:09:25 <dag> but don't we always have an output pipeline ?
20:09:37 <dag> I mean we are returning JSON output, always
20:09:37 <nitzmahone> Yeah, but that's not something we can affect.
20:09:54 <dag> so there's no real gain IIUC
20:10:24 <jborean93> swapping from `Out-Null` to `> $null` would potentially save 10s of milliseconds
20:10:27 <jborean93> on each call
20:11:00 <nitzmahone> If we want to explore this some more, I'd say let's pick a big thing like setup and measure the diff
20:11:05 <nitzmahone> I don't want to just cargo-cult it
20:11:10 <dag> ok, that could be a new guideline for developers
20:11:20 <dag> nitzmahone: I agree
20:11:25 <jhawkesworth_> but no gain if you've done say Get-Something | Select-String >$null so its only cases where you can do away with the | in a gven statement
20:11:31 <nitzmahone> Right
20:11:34 <jhawkesworth_> good point about dev guide.
20:11:52 <nitzmahone> There are definitely cases where we could use .NET instead of two PS cmdlets strung together
20:12:18 <jhawkesworth_> that is also a good point.
20:12:24 <dag> jhawkesworth_: in my interpretation, it makes no difference if there's an output pipeline set up already (as apparently the gain is about not having to set up that pipeline ever), but we already did
20:12:46 <jborean93> We are trying to avoid sending the output to the output pipeline
20:13:10 <nitzmahone> dag: that's not exactly how I read it, but regardless, we need to verify assumptions if we want to go down this route
20:13:31 <jhawkesworth_> yep, needs testing, that's understood.
20:13:34 <dag> jborean93: but if I understood it correctly the gain is not from avoid sending it to the pipeline, it's about creating the pipeline for the first time (and we can't avoid that, as we need it)
20:13:39 <dag> ok
20:14:21 <jhawkesworth_> well I'll put it on my list to have a try, starting with exec wrappers and attempting to benchmark.
20:14:23 <nitzmahone> Jon, do you want to play with it, maybe prototype changes to Setup.ps1 and do some Measure-Command loops with it?
20:14:37 <nitzmahone> I think you'd have an easier time with setup than the exec wrappers
20:14:51 <nitzmahone> (measurement wise- much more self-contained and less "jitter" from other things)
20:14:59 * dag is referring to the last comment at the bottom which is very recent (aug 8)
20:15:08 <jhawkesworth_> yes, I'll do that, good point.
20:15:14 <jborean93> The other thing I wanted to do with setup.ps1 is try to remove as much WMI calls as possible, was holding off as I believe there was talk of moving it into module_utils
20:15:15 <jhawkesworth_> will read latest comment
20:15:18 <nitzmahone> dag: me too, but I think we're reading it differently
20:15:23 <dag> ok
20:16:01 <nitzmahone> jborean93: the shape of that change would also depend on if we want to try and do "refreshable/callable facts"
20:16:21 <nitzmahone> (eg, allow arbitrary module to refresh/return a single fact)
20:16:49 <jborean93> yea, I didn't want to get my hands into it if the mechanism is going to change
20:17:29 <nitzmahone> I think we should at least prototype it- there are several places where we could use that, and I have a few ideas on how we could do it
20:17:45 * nitzmahone can't remember if he added a card to 2.5 for that or not
20:17:50 * nitzmahone looks
20:17:51 <jborean93> you did
20:17:58 <nitzmahone> ok cool
20:18:35 <nitzmahone> OK, so Jon'll let us know how the prototype works with setup.ps1 and we can go from there
20:18:37 <jhawkesworth_> I like the idea of refreshable facts.
20:18:51 <jhawkesworth_> its a plan.  shall we move on?
20:19:02 <bcoca> i might be missing something .. aren't all facts 'refreshable'?
20:19:09 <nitzmahone> Yeah, I'm not sure if it makes sense to do it with all facts, but to at least have a pattern for sharable facts
20:19:40 <jhawkesworth_> yeah some stuff simply doesn't change very often anyway
20:19:49 <nitzmahone> bcoca: we're talking from within an arbitrary module that either needs an uptodate fact value or mutates it and wants to let the control env know in the return value
20:20:19 <nitzmahone> (but so that the actual code that calculates of the fact is not duplicated)
20:20:25 <bcoca> ansible_facts.factname = new value
20:20:57 <nitzmahone> Right- we're talking about factoring out the code that actually does the calculation though
20:21:00 <jborean93> bcoca: moving it into a module_util would make sure we are using the same source
20:21:16 <nitzmahone> That'd be a part of what I'm thinking
20:21:23 <bcoca> ah, ok, so not as much 'refreshable facts' but 'reusable facts code'
20:21:27 <nitzmahone> right
20:21:49 <nitzmahone> But hopefully without the module needing to take all of setup.ps1 as a dep
20:22:05 <bcoca> well, that was part of reason we split facts.py on unix side
20:22:22 <bcoca> i would just advise to keep a simpler structure
20:22:22 <nitzmahone> Yep, we're behind the curve on some of that
20:22:46 <nitzmahone> It's an uncommon enough situation that we could probably go for "simple and cheap" from the dev side first
20:22:53 <nitzmahone> get fancy with it later if it's a problem
20:23:06 <nitzmahone> Anyhoo
20:23:24 <nitzmahone> #topic https://github.com/ansible/community/issues/195#issuecomment-335276821
20:24:20 <nitzmahone> @jborean93: this one's all you
20:24:21 <jborean93> I believe we came to a consensus to use the set name
20:24:39 <jborean93> We just unload the hive if it is already there and throw a warning instead of failing
20:24:41 <nitzmahone> Oh yeah, but have it force-unload it first
20:24:53 <jborean93> yep
20:25:24 <jhawkesworth_> I can't think of a disadvantage of doing it that way.
20:25:35 <nitzmahone> only one way to find out ;)
20:25:46 <jborean93> sweet, will merge it through
20:26:15 <jborean93> last one on the agenda
20:26:18 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-337083912
20:26:29 <jborean93> win_dsc
20:27:01 <jborean93> I really want to remove the string function for CimInstance as well as 2 of the 3 duplicate return values
20:27:18 <jborean93> Trouble is that it has been released in 2.4 and will potentially be a breaking change
20:27:54 <jborean93> For the CimInstance, we never documented it and trond never had any docs on his github page so I doubt people are using it for that  right now
20:27:54 <jhawkesworth_> I've not really strung together any stuff using win_dsc so don't have a feel for how much you'd make use of the return values.
20:28:05 <jborean93> They are all the same
20:28:15 <jborean93> the docs indicate they are different but looking at the code that is not the case
20:28:25 <jborean93> it is just what we are passing through so in reality we should remove them all
20:28:33 <jhawkesworth_> I think its forgiveable in a preview module
20:28:59 <nitzmahone> I'm leaning that way as well
20:29:21 <dag> I think we need to backport that though
20:29:38 <jhawkesworth_> I guess if invocation parms on -vvv is fixed there would be no need for any of them if its just pass through params
20:29:53 <jborean93> Technically I haven't added new features just a different way of writting it but it is a fair amount of code changes
20:31:33 <jhawkesworth_> I would definitely want to use the yaml style but I'm not using any win_dsc yet so I'm not best to ask.
20:31:56 <jborean93> It's actually pretty sweet if you have met the requirements
20:33:47 <jborean93> Should I remove all of the return values that are just invocation args as well while I'm at it
20:33:48 <jhawkesworth_> I'm hoping to be able to try out more stuff now I finally have windows VMs cloning out and joining the domain straight from playbook.
20:34:08 <nitzmahone> I would- I've got restoring `invocation` to PS stuff on the 2.5 roadmap too
20:34:30 <nitzmahone> Well, ideally, restoring it to everything- whether or not we do a PS-specific version
20:34:35 <jborean93> jhawkesworth_: that's awesome, I'm playing around with building some packer images for ultimately doing something like that
20:35:00 <jborean93> nitzmahone: cool will do that as well so we don't have to pull on that band aid in the future
20:35:53 <jborean93> What are our thoughts on backporting it to 2.4.2, I don't think we should but can see reasons why we might
20:36:31 <nitzmahone> I'd definitely lean toward "not", and I suspect Toshio might veto anyway
20:37:26 <jhawkesworth_> in a couple of places I return stuff which is based on request parameters, but only if its been modified in some way (like default tag in win_toast).  but I've been persuaded pass through params not needed.
20:38:10 <jborean93> yep, IIRC this just passes in the exact same value so add's little value, none once the invocation params is returned in 2.5
20:38:24 <jborean93> I'll triple check before removing
20:38:30 <jhawkesworth_> I guess potentially breaking changes not welcome in point releases.
20:38:39 <nitzmahone> exactly
20:38:56 <jborean93> No, I'll add it to the changelog for 2.5 regardless and actually document the new format
20:39:00 <nitzmahone> (no potentially about it, "avoided at all cost")
20:39:42 <jhawkesworth_> would mean less time for people to make  playbooks that rely on old behaviour.  but point releases are for fixing
20:40:30 <jborean93> I'm not even sure how many people are using the string format, I couldn't find any blog posts and the only example I found was from the person who added via PR
20:41:01 <jhawkesworth_> I think don't sweat it then.
20:41:01 <jborean93> plus it's a weird mixture of DSC/PS with YAML
20:41:39 <jborean93> Cool, I wanted to try and create a custom DSC resource for testing before merging and will get started on that
20:41:43 <jhawkesworth_> yeah the mixture doesn't make for easy reading
20:42:27 <nitzmahone> Similar to k=v + YAML in playbooks.
20:42:40 <nitzmahone> "Can you?" Sure. "Should you?" mmmmaybe not.
20:43:10 <jborean93> haha, yea. I like the k=v in multiple lines, a mixture of both
20:43:28 * jborean93 thinks like is not the word I'm looking for
20:43:33 <jhawkesworth_> win paths are whole lot less pain if you skep key=value
20:43:38 * nitzmahone headdesks when he sees that
20:44:31 <jborean93> #topic open floor
20:44:41 <jborean93> Anything else anyone wanted to talk about?
20:46:05 <jhawkesworth_> no just chat really.  hoping to be a bit more active now I have a working laptop again
20:47:34 <jborean93> that's good news, I've never been game to replace a laptop motherboard before
20:48:27 <jhawkesworth_> not recommended but second mobo off ebay fit my budget :-)
20:48:40 <jhawkesworth_> second = secondhand
20:49:56 <nitzmahone> I just picked up two high-hour LED projectors off ebay (they arrived 5m ago)- hoping they're worth it
20:50:45 * jborean93 knows where nitzmahone will be for the rest of the day
20:52:34 <nitzmahone> 2 years old, average "lamp" life of 20k hours, $1300 new, $100 with 15k hours on them.
20:52:48 <nitzmahone> Who the hell basically left them on 24/7?
20:53:15 <jhawkesworth_> fingers crossed.  For $100 I guess they don't have to last forever
20:53:29 <jborean93> Probably a school
20:53:31 <nitzmahone> Exactly- I need them like once a year
20:53:51 <jborean93> At my high school you walk into a room after lunch and it is still on the blue screen because someone didn't turn it off
20:53:59 * nitzmahone used to just borrow from employer's office, but my home office does not contain projectors
20:54:13 <nitzmahone> Well, I guess now it does
20:55:44 <jhawkesworth_> my home office in the roof so short of vertical spaces to project against.
20:56:26 <jhawkesworth_> employers ditched projectors for a big TV  last year.
20:57:00 <jhawkesworth_> anyway, I'll stop distracting you.
20:57:05 <jhawkesworth_> cheers
20:57:16 <jborean93> no worries, thanks for joining
20:57:19 <jborean93> #stopmeeting
20:57:29 <jborean93> #endmeeting