19:00:05 <shertel> #startmeeting Ansible Core Public IRC Meeting
19:00:05 <zodbot> Meeting started Tue Jun 29 19:00:05 2021 UTC.
19:00:05 <zodbot> This meeting is logged and archived in a public location.
19:00:05 <zodbot> The chair is shertel. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:05 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:00:12 <shertel> #info agenda https://github.com/ansible/community/issues/615
19:00:32 <shertel> it doesn't look like there's anything on the agenda today
19:00:34 <cyberpear> o/
19:00:39 <shertel> hi
19:00:42 <shertel> #topic open floor
19:00:47 <Shrews> there is one thing shertel
19:00:56 <bcoca> https://github.com/ansible/ansible/pull/74998
19:02:03 <shertel> Shrews - I don't see it
19:02:04 <mehes-kth> Hi there...
19:02:25 <mehes-kth> I seem to have gotten out and back in..
19:02:26 <shertel> Oh :-) Hello
19:02:29 <shertel> #topic https://github.com/ansible/ansible/pull/75110
19:02:30 <Shrews> shertel: bcoca mentioned https://github.com/ansible/ansible/pull/75110
19:02:53 <shertel> was waiting for it to show up on the agenda and hadn't seen the response on the PR
19:03:15 <bcoca> i mentioned another also
19:03:20 <mehes-kth> I was hoping that bcoca linking the PR would suffice
19:03:32 <bcoca> i linke/mention many things
19:04:08 <mehes-kth> OK...
19:04:18 <bcoca> so during discussion with core team we mainly had 2 issues, a) is this complexity we want to add to the core filter b) is this the correct implementation/naming
19:04:44 <bcoca> im on the fence on first, have minor comments on 2nd, but i think its more important to nail down the first before we proceed
19:05:12 <mehes-kth> Personally, I find that complexity quite useful and convenient.  Obviously...  That motivated my PR.
19:05:56 <mehes-kth> I don't know about the implementation, but I tried to take the simplest, most straightforward approach I could think of.
19:05:59 <bcoca> a few use cases might go a long way to convvince people
19:06:37 <bcoca> mehes-kth: you certainly reuse existing code very efficiently ... jsut have qualms about dictyfing list to unroll dict into list once uniqued by key
19:06:44 <mehes-kth> OK.  Hairy object, I want to change _some_ parts (or verify that those have the right fields/leaves), while I don't care about the rest.
19:06:50 <shertel> I don't have a strong opinion on the first.  I'm not sure how useful it is, since it seems like rather specific. I thought the implementation was rather nice.
19:06:57 <bcoca> but that is minor, again, adding this to core is the principal question
19:07:12 <mehes-kth> The obnject is too deep to handle manually.  To many parts to ignore, quite a handful to check/override.
19:08:23 <mehes-kth> To me, the main issue is that _in some cases_ it's quite natural to treat a list as a special hash with numerical keys.
19:08:51 <mehes-kth> Of course, if the lists are misaligned, this is not meaningful or useful.
19:10:17 <mehes-kth> @bco
19:10:44 <mehes-kth> bcoca could you be  more specific about those qualms?
19:11:31 <bcoca> i think they are secondary to first question
19:11:31 <bcoca> and im mostly expressing several opinions or comments into one
19:11:38 <mehes-kth> Basically, I've been looking for a way to check/override by **PATH**.  I can do it with `jq`'s `path(..)`/`getpath()
19:12:51 <mehes-kth> A colleague gave me the idea to check `object == object | combine(override, recursive=True)`, but this stopped at lists...
19:13:15 <mehes-kth> If there's a more "ansible-ish" way to work with paths, I'd be happy to use that instead.
19:13:47 <mehes-kth> I also found a _lot_ of questions (stackoverflow/etc) on handling nested complex objects with ansible.
19:13:49 <bcoca> not that will traverse it
19:14:28 <bcoca> well, ansible is not designed to handle compplex data .. even though i wrote a page about complex data manipulation .. its mostly something that should be done and then fed to ansible
19:14:29 <mehes-kth> In most cases, the examples are simple enough (1-2 levels) that "workarounds" can get a reasonable solution.
19:15:06 <mehes-kth> Working with cloud platforms (just about any of them), I get back arbitraarily complex objects, where much of the content is not all that relevant.
19:15:20 <mehes-kth> Right...
19:15:24 <mehes-kth> I read that, too.
19:15:47 <mehes-kth> That's when I got this spark: that `combine` _could_ actually do what I want, with just a little help.
19:16:23 <mehes-kth> Anyways... you are the "guardians" of the core; so, it's your call.
19:16:34 <Shrews> just looking at the example, it looks like 'combine' is doing positional replacement (vs. left or right priority), correct? I find that a confusing use, tbh.
19:17:10 <bcoca> Shrews: our other optoins append/prepend/replace/keep original on the lists
19:17:26 <bcoca> so this is basicalaly a merge_overwrite
19:17:27 <mehes-kth> No, I think `list_merge='combine'` will do left/right priority.  Exactly as for hashes.
19:18:17 <mehes-kth> In my mind, the best way to think about this option is to imagine that a list is really a hash.
19:18:23 <mehes-kth> I.e. instead of
19:18:32 <mehes-kth> mylist:
19:18:34 <mehes-kth> - a
19:18:37 <mehes-kth> - b
19:18:38 <mehes-kth> - c
19:18:44 <mehes-kth> think of it as
19:18:51 <mehes-kth> my_list_as_hash:
19:18:55 <mehes-kth> 0: a
19:18:57 <tadeboro> Ugh, that "array is actually a hash with integer keys" strikes waaaay to close to PHP ;)
19:19:00 <mehes-kth> 1: b
19:19:04 <mehes-kth> 2: c
19:19:05 <mehes-kth> etc
19:19:18 <mehes-kth> Javascript does the same.
19:19:25 <mehes-kth> For good reason, too.
19:19:48 <briantist> not a core member, but I have to agree that while it's nice to avoid complex data, it can be difficult to do so. Often, the easiest solution is to write your own filter plugin, but that's not for everyone, and it's much nicer if we can do what is needed with builtins (ideally avoiding super complex chaining, or using jq), so I like this, and the change seems to me like it adds something useful.
19:19:51 <mehes-kth> BUT... I'm not going to defend/argue language design here.
19:20:53 <bcoca> mehes-kth: as i said, core team was split on this, personally im fine with the feature, just needs tood docs and probably a bikeshed on name
19:21:20 <bcoca> and fine means +0 ... not against it but also not enthusiasticly for it
19:21:24 <mehes-kth> @briantist  Exactly.  I'd rather have something _relatively staight-forward_ in core, than having to write  a plugin.
19:21:25 <tadeboro> I am also not a core dev, but I feel the opposite way: if we add complex data manipulation filters to core, people will use them instead of doing the right thing and having another look at their data.
19:21:48 <bcoca> ^ and this is probably the same split we have in core
19:21:59 <Shrews> "hash_behavior" keeps popping up in my brain for some reason....
19:22:04 <mehes-kth> :^)
19:22:18 <bcoca> mehes-kth: actually i think giving us some time to mull over is better than discussing today, most of us just saw it today for first time
19:22:22 <shertel> I'm probably also +0ish. I'm not opposed to it. We may not have enough a quorum on the core team to hold a proper vote though, we usually aim for 5+ people.
19:22:26 <bcoca> i would avoid making decision today
19:22:35 <mehes-kth> OF COURSE!!! Take your time.
19:22:56 <bcoca> if you could add use cases to the ticket, it probably will help your cause
19:22:57 <briantist> we don't always control the data being given to us, especially when it comes from APIs, even some of the existing modules. I mean I'm comfortable with the dev aspects of ansible so writing a filter is no big deal, but not everyone I have to work with can or should do that.
19:23:21 <briantist> I agree that use cases and examples in the ticket itself would be very useful.
19:23:48 <mehes-kth> I'll try to embellish that PR then.
19:24:07 <bcoca> in any case, i have to say it was a very clever 'abuse' of merge_hash
19:24:08 <shertel> thanks mehes-kth
19:24:35 <shertel> #topic https://github.com/ansible/ansible/pull/74998
19:24:48 <tadeboro> I hate myself when I use heavy data manipulation in playbook because in a few months, I have no idea how that complex filter works and I have to learn it once more (just like regular expressions ;))
19:25:03 <bcoca> same, but ... life finds a way ...
19:25:09 <bcoca> to make things less than optimal
19:25:54 <shertel> vaultfilters...waiting on more feedback?
19:25:58 <bcoca> why i prefer to err on the side of flexiblity, you never know how/where people are stuck in
19:26:06 <mehes-kth> tadeboro Hopefully some use cases will show that this filter is actually _simple_ (quite natural, in fact).
19:26:18 <bcoca> shertel:  yeah, someoem kick tires, find a bug, a reason i should burn my drive and throw it in the sea
19:26:47 <shertel> tadeboro: at least it is not an addition to merge_hash!
19:27:04 <shertel> heh. I will kick some tires
19:27:06 <bcoca> mehes-kth: that will be very much based on perspective and imhe that will not be 100% .. or even 60% of user base
19:31:41 <shertel> #action shertel to kick tires on https://github.com/ansible/ansible/pull/74998 today
19:32:19 <shertel> ^ and anyone else who's interested
19:32:21 <shertel> #topic open floor
19:32:26 <shertel> anything else today?
19:35:18 <shertel> thanks for attending
19:35:20 <sivel> wow, I got lost, where has the time gone...
19:35:21 <shertel> #endmeeting