15:00:28 <bcoca> #startmeeting ansible core public irc meeting 15:00:28 <zodbot> Meeting started Thu Jan 3 15:00:28 2019 UTC. 15:00:28 <zodbot> This meeting is logged and archived in a public location. 15:00:28 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:28 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting' 15:00:57 <bcoca> #topic https://github.com/ansible/ansible/issues/49992 15:01:40 <bcoca> lucastheisen ? 15:01:42 <lucastheisen> @bcoca, we talked about this last time but there were not enough members here. are there more today? 15:01:55 <bcoca> testing 1 ... 2 ... 3 .. testing 15:02:17 * Pilou wave :) 15:02:19 <lucastheisen> might just be us again... 15:02:47 <lucastheisen> i did add another option to my writeup in https://github.com/lucastheisen/ansible-merge-vars/blob/master/README.md 15:03:07 * shertel waves 15:03:24 <lucastheisen> specifically, it would be really simple to add a `hash_behaviour: merge` argument to the `include_vars` action... 15:03:42 <sivel> I'm around 15:03:58 <lucastheisen> then the security issue doesn't matter because include_vars is already the exception to that rule... 15:07:04 <lucastheisen> would that be a workable solution? it could also, if done correctly, add the same `hash_behaviour: merge` option to `set_fact` which would also be useful to my use case. 15:07:38 <bcoca> lucastheisen: you already have that with combine filter 15:07:58 <maxamillion> .hello1 15:08:00 <maxamillion> .hello2 15:08:01 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com> 15:08:12 <maxamillion> *sigh* .... I really can't type ever since returning from the break 15:08:25 <bcoca> i could never type before break ... 15:08:30 <maxamillion> :) 15:10:34 <lucastheisen> combine filter wont work... for example, i have one var file with:{foo: {bar: baz}}, and another with {foo: {hip: hop}}... when in include_var the first, im ok, but how do i get the second included so that i can combine them? if i include_vars again, it will replace the first so i cant merge it. 15:10:47 <bcoca> i meant for set_fact 15:11:53 <lucastheisen> ah... 15:15:03 <bcoca> we still dont seem to have quorum, so im just going to postpone till tuesday ... hopefully we get people in here 15:15:05 <Pilou> that reminds me #25948 15:15:46 <lucastheisen> alright, in your opinion is the `hash_behaviour: merge` on `include_vars` something worth pursuing? 15:15:50 <sivel> Typically speaking, use of hash_behaviour=merge is not recommended, since it isn't really portable. I'm not sure that adding an arg to include_vars is the right way either. 15:16:28 <sivel> adding an arg, seems wrong, since that is yet another way to get merge behavior, but in a very restricted use 15:16:43 <bcoca> i still think a !merge directive in the vars file is the way to go 15:16:49 <bcoca> would give 'universal' support 15:17:22 <bcoca> ^ the PR Pilou links is very close to ideal way to do this 15:17:25 <lucastheisen> i think that would be _better_ as well... but that, as you mentioned, is a difficult problem and will take time to solve... 15:18:13 <bcoca> the issue is that we would also have to add smarts to our json encoder/decoder and i have not found a good way yet 15:18:15 <lucastheisen> im just looking for _any_ approved path to _limited_ merge. 15:18:20 <Pilou> it seems the only missing bits from #25948 are doc and changelog 15:18:22 <bcoca> same as handling '!unsafe' 15:18:34 <bcoca> Pilou: no, biggest issue is json encoding/decoding 15:21:59 <lucastheisen> so, to sum it up. not enough people at this meeting to make any sort of decision, but feedback from @bcoca and @sivel is that it seems unlikely that either of my suggestions will be acceptable. 15:22:06 <lucastheisen> sound about right? 15:22:30 <bcoca> yes, but i think that 25948 has a way forward that also works for you? 15:23:31 <bcoca> https://github.com/ansible/ansible/issues/47295 <= this shows the json issue, we need to be able to represent any 'yaml object' in a way that it passes json boundries, since we use those internally in some systems 15:27:52 <bcoca> anything else on this topic? 15:28:13 <bcoca> i have the json issue on my list, once sovled for unsafe we cand o same for ansiblemapping and then deal with !merge !replace handlers 15:28:38 <lucastheisen> its hard to tell at a glance, but i imagine it would. i am not sure how the yaml's would look... where would the !merge go? would it be on every leaf that needs to be merged? that would fast get ugly... 15:28:52 <bcoca> varname: !merge 15:28:55 <bcoca> key1: val1 15:29:12 <lucastheisen> then yeah, that sounds like it would work for me. 15:29:34 <bcoca> it 'could' work on keys, but mainly was thinking top level 15:30:05 <lucastheisen> yeah, that sounds like it would work. 15:31:10 <bcoca> k, then closing this issue for now, once i have time (or if someone beats me to it) we can deal with the json encoding/decoding issue and then add this feature 15:32:12 <lucastheisen> ok. 15:32:36 <bcoca> dag? 15:32:47 <dag> hey 15:33:04 <dag> are we meeting again ? I didn't know :) 15:33:07 <bcoca> not sure if worth discussing list since we are missing people 15:33:40 <dag> bcoca: pick something easy that doesn't require votes ;-) 15:33:48 <maxamillion> yeah, there's a lot of folks still on vacation 15:34:08 <bcoca> didnt we already reject required_by ? 15:34:55 <dag> bcoca: it was decided that time was better spent on a more advanced system that describes relations 15:35:07 <dag> bcoca: but since that hasn't materialized yet... 15:36:27 <dag> pick another ;-) 15:37:44 <bcoca> i dont see anything that will be a no brainer 15:37:53 <cyberpear> https://github.com/ansible/ansible/pull/50327 15:38:08 <bcoca> cyberpear: wait your turn 15:38:36 <cyberpear> Sorry 15:39:17 <dag> bcoca: ok, I'll wait 15:39:58 <bcoca> k, cyberpear, your turn now .. but i think same issue, lack of quorum 15:40:26 <dag> what is the quorum actually ? :-) 15:41:52 <bcoca> 5 core people, we are at 4 15:42:05 <cyberpear> Ok. My guess is just bike shedding on the name. Ignore the test changes, just cherry picked that to pass ci 15:43:44 <dag> well, maybe my PRs need more reviews by next meeting ? 15:44:06 <bcoca> yep, i'll add to my list, i thnk 1 of em already was on it 15:44:10 <bcoca> #endmeeting