19:59:33 <nitzmahone> #startmeeting Ansible Windows Working Grouo
19:59:33 <zodbot> Meeting started Tue Apr  3 19:59:33 2018 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:33 <zodbot> The meeting name has been set to 'ansible_windows_working_grouo'
19:59:43 <nitzmahone> Dangit
20:00:00 <nitzmahone> #chair jborean93
20:00:00 <zodbot> Current chairs: jborean93 nitzmahone
20:00:34 <jborean93> close :)
20:00:52 <nitzmahone> Stuffing lunch in my face, so using my phone
20:01:01 <jhawkesworth_> hey
20:01:17 <nwsparks> hi
20:01:57 <nitzmahone> #chair nwsparks #jhawkesworth_
20:01:57 <zodbot> Current chairs: #jhawkesworth_ jborean93 nitzmahone nwsparks
20:02:52 <jhawkesworth_> yay big turnout
20:03:11 <nitzmahone> Beats just me and Jordan ;)
20:03:34 <jborean93> It has been quite with Jon and I for the past few weeks
20:03:48 <nitzmahone> Jordan, can you run this until I get done with lunch?
20:04:19 <jborean93> sure
20:04:36 <nitzmahone> Thanks
20:04:42 * nitzmahone lurks
20:04:52 <jborean93> so there is nothing on the agenda
20:04:57 <jborean93> #topic open floor
20:05:07 <nitzmahone> Could be a quick meeting then ;)
20:05:09 <jborean93> opening it up to others
20:05:24 <jborean93> How has 2.5 been, have you been able to upgrade?
20:05:41 <nwsparks> I upgraded, no issues so far. It's been working well.
20:06:08 <nitzmahone> PS, 2.5.1 will likely be next Thursday, with following dot releases every 2-3 weeks
20:06:13 <jhawkesworth_> plan is to go to QA with it next week, production start of May for us
20:06:34 <jborean93> That's good to hear, there were a few issues that were reported and fixed after 2.5 was released so 2.5.1 should be even better
20:06:44 <dag> go/
20:06:47 <jhawkesworth_> cool would be nice if I can get https://github.com/ansible/ansible/pull/37291 in
20:06:51 <jborean93> #chair dag
20:06:51 <zodbot> Current chairs: #jhawkesworth_ dag jborean93 nitzmahone nwsparks
20:06:54 <jhawkesworth_> hey dag
20:07:15 <jborean93> yep that was my bad, I was meant to look at that last week but got caught up with a few other things on my plate sorry
20:07:38 <jborean93> Are you going to make further changes based on #ansible-meeting?
20:07:39 <jhawkesworth_> no worries, appreciate the feedback from core team meeting as well
20:08:01 <jhawkesworth_> will def change the rstrip('\r') to rstrip, still thinking about the other feedback
20:08:04 <dag> nitzmahone: to get something backported, do I make the PR for 2.5 myself ? Or just put it on the 2.5 backport project ?
20:08:57 <nitzmahone> Go ahead and backport PR yourself
20:09:13 <dag> ok
20:09:22 <nitzmahone> As long as the original has landed in devel, you can also merge yourself when green.
20:09:32 <nitzmahone> Usual care required of course ;)
20:09:44 <jborean93> nitzmahone: we still planning on doing the changelog fragments in devel?
20:10:04 <nitzmahone> Yes, I'm going to create the structure today and hopefully sanity tests this week
20:10:23 <jborean93> sounds good
20:10:44 <nitzmahone> Still digging out from conferences and PTO, and another conference next week
20:10:50 <daBONDi> i upgrade to 2.5 also, run flawless :-) and was epic in the need of the new become stuff, goot work here!
20:11:43 <jborean93> nitzmahone: possible the upgrade of Fedora on the laptop :)
20:11:49 <jborean93> s/possible/possibly
20:11:53 <dag> jborean93 had a big hand in all that \o/
20:12:19 <nitzmahone> Oy, still need to
20:13:06 <jborean93> I might actually bring this up again considering we have more people this week
20:13:27 <jborean93> #topic win_dsc return params https://github.com/ansible/community/issues/294#issuecomment-376009166
20:13:59 <jborean93> Basically we removed the code that returned the input options to DSC in 2.5
20:14:22 <jborean93> This really did nothing at the time as it just returned what we actually input from Ansible
20:15:05 <jborean93> We could take it a step further and return the parsed version (what we call DSC with) but this gets quite messing when it comes to dict params
20:15:26 <jborean93> An example of this is here https://github.com/ansible/ansible/issues/37882#issuecomment-376008983
20:17:08 <jhawkesworth_> when you say 'quite messing' do you mean its tricky to generate the output if you have dict params, or just there is a _lot_ of output if you?
20:17:24 <jhawkesworth_> if its just lots of output, I'm fine with that.
20:18:21 <daBONDi> my 2 cents is, i had problems with converto-json while writing some dsc modules, because the convertto-json sometimes fail on conversation of specific .net objects, so maybe an errorpoint in the future with some dsc resources, when the level is to deep
20:18:22 <jhawkesworth_> I still think an 'output_mode' param where default 'normal' mode is as now and 'debug' mode gives you parsed parameters would be best
20:18:31 <daBONDi> maybe add an deep level to it
20:18:51 <jborean93> s/messing/messy/
20:19:09 <jhawkesworth_> I am not speaking from any useful experience with win_dsc here, just thinking how it fits in with rest of ansible
20:19:13 <jborean93> sorry I meant that output is quite verbose as the type of object dicts turn into are not really dicts
20:20:07 <jborean93> I believe we have a depth level of 99 as well
20:20:44 <jhawkesworth_> cool, i don't think it matters if there is a lot of output if it is only restricted to when you have explicitly asked for debug output
20:20:44 <nwsparks> can it be returned for specific verbosity levels? Looks like Trond was asking about that, "maybe only in "vv" mode (are powershell modules able to pick up the verbosity from one of the "internal" params?)"
20:21:04 <jborean93> I believe it can but dag had some objections to that
20:21:29 <jborean93> We've said no to that functionality in module PRs before as well
20:22:16 <nwsparks> Hmm, so if it did output something like this, https://github.com/ansible/ansible/issues/37882#issuecomment-376008983 it would be in the default verbosity?
20:22:46 * nitzmahone relocates, biab
20:22:51 <daBONDi> probly nwsparks path would be the best path i think in this case, if i count a vote :-), and would for me be the logical one i would choose to debug my playbook
20:23:21 <jborean93> nwsparks, that's up to the implementation but probably not
20:23:48 <jborean93> trond is saying when it is -vv but we can set it to whatever
20:26:31 <jborean93> but IMO it's a bit useless only returning information based on the `-v` level
20:26:57 <jborean93> if we return the values we should just return it always
20:27:22 <daBONDi> do awx capture this, that could also be a painpoint with so much capturing into it
20:28:06 <nwsparks> It's nice for debugging in some cases....and for this specific scenario, I'd hate to see a giant return like this every time I ran the playbook.
20:28:19 <jhawkesworth_> I can see the appeal of just being able to re-run playbook with -vv on the end to get the debug info, but I'd like to be able to limit huge module responses if I don't need them
20:28:30 <nwsparks> Yah
20:28:44 <jborean93> well you wouldn't see if it is itsn't at least `-vv`
20:28:56 <jborean93> unless you run a debug task and in that case you are really debugging
20:29:35 <daBONDi> maybe make an additonal param, to strip the conversion to like 3 levels to default, and more levels on param
20:29:56 <jborean93> that's really just bad UI IMO
20:30:33 <nwsparks> I guess if we are looking at making this change solely based on this issue, maybe we could just consider the issue an edge case we wouldn't likely run into again? It should still be debuggable by running the module manually via powershell outside of ansible
20:30:45 <daBONDi> but from the other point of view, if you got a problem with a dsc resource you should debug the dsc resource itself, so the dsc result has no value in ansible for debugging purpose
20:30:50 <nwsparks> Like how useful would this return info really be for the future
20:31:05 <jborean93> not too useful but I can see where it can help
20:31:31 <jborean93> Ultimately I still had to debug it locally to figure out what was happening on the underlying issue anyway
20:32:00 <daBONDi> only edge case would be type conversion debugging
20:32:30 <daBONDi> like trond had :-)
20:32:45 <jborean93> yep
20:33:26 <daBONDi> maybe utilze it only on ansible_keep_remote files?
20:33:26 <jborean93> This is only useful to people who understand how DSC works, usually people at that level are able to debug it manually
20:33:46 <jborean93> For just standard users I don't see how they would understand the value
20:33:56 <nwsparks> That is a good point
20:35:27 <nwsparks> So the options for resolution would be - no output (current), output at specific verbosity (potential issues per dag), output into default verbosity?
20:35:47 <daBONDi> Maybe on ansible_keep_remote_files, save also the generated dict to disk, so a type conversion error could be easy debugged ?
20:36:24 <daBONDi> and remove the output
20:37:36 <jborean93> ansible_keep_remote_files is another problem in itself :)
20:37:46 <daBONDi> :-)
20:37:51 <jborean93> it saves the file and arguments but it's in the form of the exec_wrapper
20:39:14 <daBONDi> when ansible_keep_remote_files is set, dsc module saves generated object to disk with export-clixml, if this flag getting passed into a module?
20:39:30 * nitzmahone respawns
20:39:47 <daBONDi> than you could import it again in a .net object for analyze later
20:39:48 <jborean93> I'm not sure you can access keep remote files in the module, plus I believe that to be poor UX
20:40:13 <jborean93> I did toy with the idea with that being an option, like `state: export`
20:40:51 <jborean93> but it still fell short with, if you are going through that trouble why not just debug it locally like you would with any other module
20:41:01 <daBONDi> thats even a better idead jborean
20:41:44 <jhawkesworth_> its also serialisation to a different format (which presumably isn't what actually got presented?), so might not actually help with type conversion mismatch
20:42:13 <jhawkesworth_> ^ I admit I am speculating a bit here as I don't know how dsc works
20:42:17 <jborean93> the clixml helps as you can import straight back in but ultimately it won't affect the parsing code
20:42:55 <jborean93> I still think in this case if you want to play around with it you should just run it locally like https://docs.ansible.com/ansible/2.4/dev_guide/developing_modules_general_windows.html#windows-debugging
20:42:58 <jhawkesworth_> no shortage of parsing through all the layers in ansible before it hits powershell of course
20:43:23 <jborean93> You gain little with exporting/importing the clixml and have full control over debugging win_dsc by running it locally
20:43:26 <jhawkesworth_> yep, cut out all the extra stuff until you have figured out what is wrong
20:43:32 <nwsparks> I'd be in favor of leaving this as is after discussing, no output.
20:43:59 <jhawkesworth_> +1 to leave it alone
20:44:27 <daBONDi> +1 to leave it like it is = no Output, normaly ppl using dsc resources, should be able to debug this stuff :-)
20:44:52 <jborean93> +1 leave as is as well
20:45:02 <daBONDi> ansible is no office tool, you should understand whats happen in the backend :-)
20:45:09 <jborean93> sounds like a consensus. Will update the agenda item and issue
20:45:27 <jhawkesworth_> cool
20:45:39 <daBONDi> :thumbsup: if it would work :-)
20:46:12 <jborean93> Ok, with that out of the way, anything else we wanted to discuss?
20:46:40 <jhawkesworth_> looking back over agenda still curious if the pester module fits in with the testing work nitzmahone has been looking at, but it can wait
20:47:10 <nitzmahone> There's nothing wrong with a pester module IMO, but what we'll end up doing for that will likely be a lot more compelx
20:47:12 <nitzmahone> *complex
20:47:19 <nitzmahone> (not just a module)
20:48:08 <daBONDi> build a test-kitchen into ansible for windows :-)
20:48:15 <nitzmahone> Basically...
20:48:51 <nitzmahone> We'll need a framework to get the tests and bits-under-test over there, as well as a way to consume the output via ansible-test
20:48:58 <jhawkesworth_> yeah it seemed a nice enough addition, just wanted to pause in case it might make core testing harder to achieve
20:49:40 <nitzmahone> We may also do some things around data-driven repetition over what pester already provides- mainly as a way to do more performant testing of modules that are expensive to test via roles.
20:49:45 <nitzmahone> Nope
20:50:01 <jhawkesworth_> cool
20:50:18 <nitzmahone> We likely won't use it, but if it scratches a few folks' itches, more power to them.
20:51:13 <jhawkesworth_> great.
20:53:35 <jhawkesworth_> Well I've nothing else to add on that.
20:53:57 <nitzmahone> Anything else for today?
20:54:13 <jhawkesworth_> not from me.
20:54:17 <nwsparks> not for me guys
20:54:23 <jborean93> I'm good
20:54:24 <nwsparks> gonna take off and try to beat the traffic. cya next week
20:55:43 <jborean93> cya
20:55:49 <jborean93> well will bring it to a close
20:55:52 <jborean93> thanks everyone
20:56:05 <jborean93> #endmeeting