20:00:45 #startmeeting Ansible Windows Working Group 20:00:45 Meeting started Tue Jul 24 20:00:45 2018 UTC. 20:00:45 This meeting is logged and archived in a public location. 20:00:45 The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:45 The meeting name has been set to 'ansible_windows_working_group' 20:01:00 hey 20:01:04 hey 20:01:05 o/ 20:01:12 #chair jhawkesworth_ nitzmahone 20:01:12 Current chairs: jborean93 jhawkesworth_ nitzmahone 20:02:03 #topic https://github.com/ansible/community/issues/294#issuecomment-407468050 elapsed time in module return 20:02:11 this is in relation to https://github.com/ansible/ansible/pull/37969 20:02:24 yeah. 20:02:48 I think we want to keep profiling kinds of info at the controller level 20:02:49 Personally I'd be happy to add what there is in the PR 20:02:51 looking at the PR it may need some further input from the core side as well 20:03:46 yea looks like a lot of duplicated code that would be easily handled from the controller side 20:03:56 o/ 20:04:01 If anything, maybe a larger "profiling mode" sort of thing where modules can return a dict of structured timing data 20:04:09 But I don't think we want to just do it adhoc like this 20:04:13 I can see a case for having this for having on modules that fetch remote stuff 20:04:29 jborean93: for the selected modules I think it makes sense to have it there always 20:05:10 jborean93: we already have profiling options when you want to profile everything 20:05:31 some kind of profiling decorator would be nice 20:06:12 #chair dag 20:06:12 Current chairs: dag jborean93 jhawkesworth_ nitzmahone 20:06:17 BTW win_get_url already did this, but was undocumented 20:06:32 some other modules like win_shell/command have something similar 20:06:38 wait_for did it, but win_wait_for didn't IIRC 20:06:47 something similar in win_msg I think 20:07:05 they have start-time and stop-time (which is arguably less useful) 20:07:40 I don't have strong feelings about it for the modules you've added it to 20:07:43 so for both get_url and win_wait_for, it's actually feature-parity 20:08:00 Maybe I misunderstood- thought you were proposing adding it generally to lots of thinhgs 20:08:04 for uri/win_uri I added it because it is similar in nature to get_url 20:08:17 no only to get_url/uri/wait_for 20:08:27 (and windows versions) 20:08:36 yeah it was me who wondered if it ought to be more generic 20:08:38 yea I don't mind either way if it is just those modules 20:09:32 that's why I state 'select' module, is that not correct English ? :) 20:09:40 select modules 20:10:28 no it's correct, my mind hasn't fully awaken yet 20:10:42 I think I have confused things by the way I added comment to agenda 20:10:49 awakened* 20:10:52 * nitzmahone is also multitasking, so I just glanced over the PR 20:11:16 I like the idea of having 'elapsed' in module return values, then you can reason with it in your playbooks. 20:11:50 will have a look through today and do the review 20:12:08 I can see adding a download time test to my 'pre-flight checks' before prod deployment runs 20:13:08 thanks. 20:13:54 It doesn't actually stop doing something more generic. 20:14:57 Cool... Any other pressing matters for today? 20:15:13 not from me 20:15:55 nope 20:15:56 except 20:16:12 Great to see Jordan fixing so many things :-) 20:16:28 hear! hear! 20:16:46 that win_user thing that's been around for ages in particular 20:16:47 * jborean93 usually fixes things I break 20:17:29 jborean93: but you're fixing more than you break, that's what I am saying 20:17:49 I try to anyway :) 20:17:53 let me rephrase that: 20:17:53 Great to see Jordan fix more things than he breaks 20:18:00 it doesn't have the same ring to it :-) 20:18:16 :-) 20:18:35 honestly, if you see where we were coming from... 20:19:43 close this meeting now, before I become sentimental 20:20:16 #endmeeting