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