20:00:01 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Sep 25 20:00:01 2018 UTC.
20:00:01 <zodbot> This meeting is logged and archived in a public location.
20:00:01 <zodbot> 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 'ansible_windows_working_group'
20:00:06 <jhawkesworth_> hey
20:00:53 <nitzmahone> #chair jhawkesworth_
20:00:53 <zodbot> Current chairs: jhawkesworth_ nitzmahone
20:01:20 <jborean93> hey
20:01:30 <nitzmahone> #chair jborean93
20:01:30 <zodbot> Current chairs: jborean93 jhawkesworth_ nitzmahone
20:01:44 <nitzmahone> #info agenda https://github.com/ansible/community/issues/294
20:01:55 <nitzmahone> I only see a couple open items that need discussion
20:02:29 <jborean93> #topic https://github.com/ansible/community/issues/294#issuecomment-420062901 shell new console
20:02:51 <jborean93> basically just wanting to test the waters as to whether we should expose this flag in win_shell/win_command
20:03:02 <jborean93> I've been leaning away from this as you can use async to achieve the same result
20:03:17 <jborean93> but thought it best to ask anyway
20:03:47 <nitzmahone> I could go either way on this one; since we're creating a new shell anyway, I don't necessarily think it's bad to add a flag to avoid creating the console, but yeah, async works too
20:04:37 <nitzmahone> The current stuff is kinda implicit and subject to change
20:04:43 <nitzmahone> (implementation detail, vs explicit)
20:05:11 <jborean93> yea, we changed once away from this to get console encoding more uniform so it could change again
20:05:20 <nitzmahone> Explicit is fine so long as nobody can think of a situation where we wouldn't be able to honor the flag
20:05:39 <jborean93> psrp would always create a new console IIRC
20:05:59 <jborean93> the process that runs the runspace doesn't have a console to inherit anyway
20:06:15 <jborean93> so that flag would be useless in that situation
20:06:38 <nitzmahone> Yeah... So maybe just leaving it alone is the best then
20:07:21 <nitzmahone> IIRC the AllocConsole will happen automatically in any case where there isn't one already, right?
20:07:39 <jhawkesworth_> yeah.  unless there really is something you can't do by using async then adding flag seems to be over the top
20:07:50 <jborean93> yep
20:08:17 <nitzmahone> Yeah, let's just leave it then
20:08:26 <jhawkesworth_> it is revisitable if something else crops up.  I had no idea there were so many process creation flags!
20:08:41 <nitzmahone> oy, yeah, the interactions between them are ... fun
20:08:52 <jborean93> cool, will leave it be
20:09:36 <jborean93> the next one is about win_nssm, I was talking to ksubileau the other day and he's working forward on that
20:10:05 <jborean93> I'm happy to keep https://github.com/ansible/community/issues/294#issuecomment-423036010 and talk about that more at fest
20:10:10 <jborean93> unless we want to discuss it now
20:10:48 <jhawkesworth_> fest works for me
20:11:03 * jhawkesworth_ still working on powerpoints.  oops
20:11:13 <nitzmahone> yep- just have to make sure we meet up late enough in the day that Jordan's awake to discuss ;)
20:11:30 <jborean93> jhawkesworth_ I'm hoping you have lots of word arts and animations ready :)
20:11:34 * nitzmahone will probably be working on them up until an hour or so before
20:12:51 <jhawkesworth_> yeah its going to look like the web in 1995.  grey background, liberal use of blink tag :-)
20:13:51 <jborean93> hopefully lots of star wipes as well
20:14:46 <jhawkesworth_> oh yes.  flying in text as well
20:14:56 <jborean93> I'm excited to see it
20:15:04 <jborean93> I've got nothing else to talk about
20:15:17 <nitzmahone> nor me
20:16:39 <jhawkesworth_> nor me.  I will be plugging doing a comunity sprint on the thursday of Fest week, unless anyone has objections
20:17:34 <jhawkesworth_> my plan is just to do some triage of the open windows stuff and be around to unblock if anyone else is trying to fix stuff
20:17:43 <jborean93> sounds like a good plan
20:17:43 <nitzmahone> WFM- I may leave a little early on Thursday, currently scheduled to leave Friday late afternoon, but an extra day at home before Chocofest would be nice
20:18:18 <jborean93> I'm not sure what times I will be online but am attempting to make the end of the contributor day in time for the Windows break out session
20:19:07 <jhawkesworth_> my plane isn't till Friday - off to Atlanta for a week to skill up my colleagues
20:20:03 <nitzmahone> Noice. Have a Coke for me ;)
20:20:21 <jhawkesworth_> :-)
20:20:30 <ksubileau> Hi everyone, about #43406 and #44755, I would like to know if there is something more I can do on this ?
20:21:05 <jhawkesworth_> hi ksublieau
20:21:14 * jhawkesworth_ goes to look
20:21:50 <jborean93> hey, for 44755 I need to look over the changes and we can go from there
20:21:56 <jborean93> haven't touched the RDS stuff yet sorry
20:22:13 <nitzmahone> I think I was generally OK with 43406 (looked it over a few weeks ago), just needs to be updated for "version_added: '2.8'"
20:22:36 <ksubileau> no worries :)
20:22:49 <ksubileau> Ok, i can do that
20:23:56 <ksubileau> For #44755, I've also push the next PR with the additional changes we already talk about (#45693)
20:25:50 <ksubileau> And for #43406, there was some points that i'm not totally confident with, see my comment https://github.com/ansible/ansible/pull/43406#issuecomment-416667653
20:27:20 <nitzmahone> I think most of the things you brought up there are OK as-is
20:27:33 <ksubileau> Ok, fine :)
20:28:09 <nitzmahone> The "unlimited" vs "-1" thing could be easily handled with by checking for "unlimited" as a value
20:29:11 <nitzmahone> The other UI concerns I think are generally OK as-is; I don't usually hate too-long arg names when they're more descriptive (esp since we can always add aliases to shorten), but too-long module names are annoying if they're using common acronyms
20:29:23 <ksubileau> Yes, easy but just need to drop the integer type on the parameter
20:29:56 <nitzmahone> (ie, expanding the acronyms in module names is worse IMO than having the names be a little more cryptic, esp if the module descriptions include the typical terms people would search for)
20:30:27 <nitzmahone> right
20:30:46 <jborean93> shorter module names are a +1 for me
20:31:11 <jhawkesworth_> MS saddled the whole thing with long names to start with.  I think the modules names are fine, very unlikely to clash with anything else, which would be my only other concern
20:31:24 <ksubileau> Maybe the concern here is that the name of two module differs only by one letter
20:32:11 <nitzmahone> That'll be less an issue once we have positive arg validation (probably available in 2.8)
20:32:18 <ksubileau> Maybe it's prone to copy/paste errors, a bit hard to find
20:33:10 <ksubileau> What is it ? a reference ?
20:33:31 <nitzmahone> They're common acronyms for those things though, so I'm not too worried about that
20:33:53 <nitzmahone> (new thing coming that will cause Windows modules to error if you give the wrong arg names to a module)
20:34:11 <nitzmahone> Python module already have this, but Windows has not to date
20:34:12 <jhawkesworth_> and its hard to make a sensible alternative name without making it long
20:34:16 <nitzmahone> Exactly
20:34:40 <nitzmahone> You'd either be making up a new acronym that isn't in general use or abbreviating things (or just making it really long)
20:34:59 <nitzmahone> People who need to administer RDS generally know what RAP/CAP are
20:35:49 <nitzmahone> So trust your gut- you got it right the first time (IMO) ;
20:35:51 <nitzmahone> ;)
20:36:05 <ksubileau> Perfect !
20:36:43 <ksubileau> Just one thing, about return values
20:36:44 <jhawkesworth_> setting up RDS not something I've ever had to do so I'm not best placed to comment.
20:37:20 <nitzmahone> Oh yeah, simple is generally good on those IMO; better to have a separate facts module for those instead of returning the full state
20:37:27 <jhawkesworth_> in general terms I like it best when modules tell me the state the thing you are managing has arrived at following the module completion
20:37:38 <ksubileau> I didn't really find a common pattern in existing values
20:38:20 <jhawkesworth_> best when it returns the things that you need to feed into other module calls
20:39:24 <nitzmahone> We've been trying to move to simpler in general
20:39:30 <ksubileau> Ok so the idea is more to return values if they may be chain with other modules ?
20:39:37 <jhawkesworth_> yeah it varies a lot based on what you can get at.
20:39:49 <nitzmahone> Returning changed values in diff-mode is good, but a complex return with the current state is usually not helpful over what a facts module could provide
20:40:34 <nitzmahone> Yeah, returning stuff that's useful for other modules is good, so eg, if it created a thing that has a server-assigned ID that you might need to reference in another task, returning the ID is good
20:40:35 <jhawkesworth_> that's the way I like it, but it has to be the useful stuff, not just everything
20:40:56 <jhawkesworth_> yeah facts modules are the way to go if there's a boat load of detail to pass around about an object
20:40:58 <nitzmahone> In these cases, not sure there will be a lot that's useful to return, as most of these calls aren't very chainable
20:41:37 <jhawkesworth_> yeah sorry I'm just stating a general preference, no experience of rdg management specifically
20:42:18 <ksubileau> That's is also a general question not absolutly specific to RDS
20:43:48 <nitzmahone> Yep- we've been trying to encourage simplicity and only returning stuff that's immediately useful (vs a full SDK return value or "dump the entire state of the thing")
20:44:30 <ksubileau> Yes and indeed there is no need to return a value provided in input
20:44:40 <nitzmahone> yep
20:45:04 <ksubileau> Ok, that's clear to me :)
20:45:16 <ksubileau> thanks
20:45:27 <nitzmahone> Cool- anything else for today?
20:45:30 <jborean93> makes the module a lot simpler as well
20:45:35 <nitzmahone> +1000!
20:46:17 <jhawkesworth_> not from me.
20:46:23 <nitzmahone> closing in 5...
20:46:27 <nitzmahone> 4...
20:46:31 <nitzmahone> 3..
20:46:33 <nitzmahone> 2..
20:46:35 <nitzmahone> 1..
20:46:40 <nitzmahone> Thanks all!
20:46:45 <nitzmahone> #endmeeting