19:04:24 #startmeeting ansible core irc plublic meeting 19:04:24 Meeting started Tue Jul 9 19:04:24 2019 UTC. 19:04:24 This meeting is logged and archived in a public location. 19:04:24 The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:04:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:04:24 The meeting name has been set to 'ansible_core_irc_plublic_meeting' 19:04:43 #topic https://github.com/ansible/ansible/issues/53402 19:04:52 @mavit? 19:05:11 +1 to `regex` vs `regexp` 19:05:26 it's thrown me off multiple times 19:05:37 its just one of many things that make me hate lineinfile 19:06:04 fyi, it already has regex alias 19:06:08 hmm 19:06:12 good to know 19:06:15 fixed that a while back 19:06:31 +1 to `regex` 19:06:45 +1 also to regex (use regexp as alias for backwards compat) 19:07:11 .hello2 19:07:12 maxamillion: maxamillion 'Adam Miller' 19:07:13 we should add an alias also to the `replace` module 19:07:52 all those listed in ticket that have regexp 19:08:36 I'd be in favor of updating all of the above to use `regex` at least as an alias 19:08:54 also +1 to regex with alias for backwards compat 19:08:55 i would make it principal and regexp the alias 19:09:11 +1 to regex 19:09:15 (if/when modules are moved out of core, it'd be more difficult to do such module param standardization work) 19:09:41 cyberpear: not that being in core has worked wonders for that 19:10:06 at least `replace` is `stableinterface`, so the alias should probably stick around for a while 19:10:19 it used to be the case when 'core team' was 3 people and we reviewed all modules, but unless we start using enforcement for 'sounds like' in options, its not scalable 19:10:30 im fine with alias being permanent 19:12:13 +1 regex w/ backwards compat 19:12:51 so let me put up options a) regexp with regex alias, b) regex with regexp alias c) we stop using regexes 19:12:55 b+1 19:13:25 b+1 19:13:30 b+1 19:13:47 b+1 19:14:20 b+1 19:14:50 * bcoca is suprised no one went for c 19:15:02 k, calling it then 19:15:18 #topic to combine with options or to combine_deep 19:15:28 https://github.com/ansible/ansible/pull/58798 19:15:35 https://github.com/ansible/ansible/pull/57894 19:15:38 both options 19:15:46 a+1 19:16:01 b+1 19:16:08 ^ as of interface, code review might get more traction, specially b 19:16:41 sorry, im b+1 19:16:50 ^ 'specially a) 19:17:33 > as of interface, code review might get more traction 19:18:02 a) new filter, b) new option on existing filter 19:18:14 b+1 19:18:16 ^ for some reason those were reversed in my head 19:18:33 sorry, was distracted classifying files 19:18:50 just to be sure of what you mean : you said the interface will be discuss during code review, not during the meeting 19:19:04 ? 19:19:30 the 2 options are about which interface to use (most of the code is same, just organization and invasiveness, updating hash_merge makes me uneasy) 19:19:36 hi 19:19:42 ok 19:20:39 so for now, it's a:0 b:3 19:23:13 i dunno, i like a for the fact that it doesn't complicate merge_hash 19:25:13 bcoca: are you ok to discuss implementation after the meeting ? (or after the a/b vote ?) 19:25:21 w/o a new filter, `list_merge` is meaningless for non-recursive 19:26:16 cyberpear, yes it is: `{"a": ["toto"]} | combine({a: ["titi"]})` 19:27:03 okay, if list_merge is meaningful for non-recursive, there's no reason to have a separate filter, in my mind 19:27:04 tchernomax: i'll update ticket 19:27:18 bcoca: ok 19:27:24 thanks 19:28:15 b+1 19:28:25 jtanner: are you voting "a", or are you undecided ? 19:28:38 for now, a:0 b:4 19:28:41 i probably don't have grounds to vote 19:29:33 looks like there is one task in 'filters' target that use 'combine' and expects success... adding tests for the current behavior as well as the feature seem important 19:29:34 (some others may hesitate… but indeed I think "b" will win) 19:30:24 +10 for tests 19:30:24 shertel: you, I didn't implement test and documentation yet. But it's in my TODO. 19:30:38 ^ we needed to decide approach first 19:30:44 I did read that, just reiterating 19:31:04 I wanted to now if I should focus on a or b before going further 19:33:15 k, i think you got your answer 19:33:20 #topic open floor 19:33:35 #topic ansible_remote_tmp and ansible_async_dir 19:33:43 are these connection variables? 19:33:48 they seem to be poorly documented 19:33:54 first is .. 2nd ... mebbe 19:34:19 defaulting to $HOME/.ansible and $HOME/.ansible_async 19:34:25 any var that is in connection/shell/become plugins + ansible_python_interpreter are 'connection variables' 19:34:39 I couldn't find very good docs on them, but the latter was in the 2.8 porting guide 19:34:58 ansible_remote_tmp is in shell plugins 19:35:02 ansible_remote_tmp is where remote temp files are placed 19:35:17 ansible_async_dir is the directory the async result files are placed 19:35:20 shell plugins++ 19:35:22 IIRC both are documented in the shell plugins 19:35:28 * cyberpear looks 19:35:32 i dont think async is in shell plugins 19:35:52 async is 'action plugin/module' based 19:35:56 I'm 95% sure I did that there for powershell 19:35:59 its currently in weird state 19:36:01 * jborean93 checks 19:36:05 jborean93: that is the exception then ... 19:36:09 bingo! https://docs.ansible.com/ansible/latest/plugins/shell/sh.html 19:36:19 thanks! 19:36:25 #topic open floor 19:36:30 https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/doc_fragments/shell_common.py#L33 19:36:30 lib/ansible/plugins/doc_fragments/shell_common.py <= aysnc_dir is here ... i sit corrected 19:42:44 https://github.com/ansible/ansible/tree/devel/contrib#contributions-welcome <- can I update it to welcome bug fixes and direct new scripts/features to plugins? That's been done on an individual basis for a while, but I didn't realize there was out of date documentation. 19:42:58 +10K 19:43:10 even pushing to new repo ansible/inventory_scripts 19:49:43 nothing else? 19:50:04 * jborean93 cricket 19:50:08 #endmeeting