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