15:30:43 <Shrews> #startmeeting Ansible Core Public IRC Meeting
15:30:43 <zodbot> Meeting started Thu Jul  8 15:30:43 2021 UTC.
15:30:43 <zodbot> This meeting is logged and archived in a public location.
15:30:43 <zodbot> The chair is Shrews. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:30:43 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:31:16 <Shrews> #info agenda https://github.com/ansible/community/issues/623
15:31:47 <Shrews> #topic https://github.com/ansible/ansible/pull/75110
15:32:01 * shertel waves
15:32:24 * bcoca waves
15:32:37 * sdoran surfs
15:32:45 <bcoca> still +0 on list combine
15:32:54 <mehes-kth> I made an update both to the code (to avoid sorting for efficiency) and to the description (to include use cases, as agreed last time). I'm looking for feedback/decision
15:33:46 <bcoca> hopefully we get quorum today
15:35:34 <sivel> aside from the actual feature itself, the code definitely concerns me, and based on the current implementation alone, I'm -1. I haven't evaluated whether it can be done with less indirection and hoops
15:36:13 <sdoran> That was my feeling. The current implementation is a bit too clever though I'm not opposed to the feature.
15:36:52 <Shrews> i am also not opposed to the feature itself, though i have not closely reviewed the code
15:37:33 <shertel> I'm still +0ish regarding the feature itself
15:37:36 <mehes-kth> @sivel Indirection and hoops?  Care to explain?
15:37:57 <bcoca> sivel: im +0 on feature, which is what we were discussing, code review can follow
15:38:32 <bcoca> do we all agree on the feature? we can then deal with implementation
15:38:38 <mehes-kth> Never mind.  Please decide on the feature first, then...
15:38:56 <bcoca> implementation becomes irrelevant if the feature itself is rejected
15:39:01 <mehes-kth> Correct
15:39:19 <sivel> I'll say +0 on feature as well.  And without anyone actually saying +1, I'd fall back to a `0` having the same meaning as "no"
15:40:23 <sdoran> mehes-kth: Changing the list into a dict using the list address as the key was one area of concern.
15:40:38 <bcoca> i tend to agree, if majority +0 is one thing .. no +1 ... means noone in core is very sure this is warranted nor maintainable
15:41:05 <sdoran> Not that it's _wrong_ just seems convoluted.
15:41:15 <bcoca> sdoran: lets stay on 'feature' since implementation is 2ndary to that
15:41:24 <sdoran> 👍
15:41:32 <mehes-kth> sdoran  OK..
15:42:43 <Shrews> If anyone wants this feature to move forward, please speak now, or else we'll agree to reject it.
15:42:47 <bcoca> mehes-kth: also with example given .. i would almost say to use yaml anchors .. that wont work across files though so still a case for that
15:42:50 <mehes-kth> Since I'm _very_ new here, could you explain (a) who has voting rights and (b) when are they expected to actually express their decision?
15:43:23 <sivel> mehes-kth: largely the core team, those here commenting with an @
15:43:23 <bcoca> mehes-kth: everyone can express opinion, but core team/contributors have more weight in vote
15:43:40 <bcoca> if no one in core is in favor, we consider a veto
15:43:51 <bcoca> consdier it a veto
15:44:16 <mehes-kth> Is there any requirement on the number of votes?
15:44:29 <mehes-kth> How many are in the "core"/etc?
15:44:38 <mehes-kth> Just wondering...
15:44:42 <bcoca> good question ... keeps changing
15:45:01 <sdoran> 🙊
15:45:04 <bcoca> right now i would consider all that have typed in channel aside from you '
15:45:08 <mehes-kth> What's your quorum then?  The minimum number required for a decision?
15:45:09 <sivel> we tend to go with 5 members of core defining a quorum
15:45:10 <bcoca> core' , though some are about to move
15:45:17 <shertel> sivel, bcoca, sdoran, shrews, myself are coreish
15:45:30 <bcoca> quorum will have to change since 'core' is also changing, but for now 5 as sivel said
15:45:35 <mehes-kth> OK.  I haven't counted... Did we get 5 +0 votes?
15:45:36 <sdoran> Not to be confused with rhelish.
15:45:41 <shertel> heh
15:45:58 <bcoca> k. letse make it numeric, please vote to include/reject feature:
15:46:00 <sdoran> I am +0 to the feature.
15:46:00 <bcoca> +0
15:46:02 <mehes-kth> In that case, let's consider this done, and move on...
15:46:05 <shertel> +0
15:46:08 <Shrews> +0
15:46:38 <Shrews> sdoran?
15:46:49 <sivel> +0
15:46:51 <sdoran> Excellent explanation and reasoning, but ultimately I believe this is better suited to a custom plugin outside of Core.
15:46:55 <bcoca> mehes-kth:  so sadly we are going to reject this, but we are all +0 so if you can find more compleling cases and/or more people to support it , might get a different result in future
15:47:33 <Shrews> #agreed the combine list_merge feature in 75110 will be rejected
15:47:48 <mehes-kth> I have a custom plugin doing this already (as _also_ documented in the PR); so, I don't really care; although I do think it's a pity...
15:48:04 <Shrews> we'll move on
15:48:07 <Shrews> #topic https://github.com/ansible/ansible/issues/75212
15:48:24 <Shrews> this has not yet gone through triage it seems
15:48:35 <mehes-kth> Based on discussions on the issue, I'll file a bug upstrream.  DONE>
15:48:57 <Shrews> easy enough
15:49:24 <Shrews> #agreed mehes-kth to file bug upstream (re: 75212)
15:49:30 <Shrews> #topic open floor
15:50:00 <bcoca> Shrews:  but loader one already has 2 core opinions, which seem to match, not sure if we should just decide now on it
15:50:45 <sivel> Do nothing +1 :)
15:50:57 <bcoca> mehes-kth: my reasoning on it is that C parser does have issue with corner cases, but libyaml project are normally good in handling those isssues adn fixing them
15:50:59 <Shrews> #chair bcoca sdoran sivel shertel
15:50:59 <zodbot> Current chairs: Shrews bcoca sdoran shertel sivel
15:51:08 <Shrews> ^ in case i lose power due to storm
15:51:29 <sdoran> Given how noticeably slow the Python  parser is, I _really_ don't like the idea of preferring that.
15:51:32 <bcoca> but w/o C parser ansible becomes unbarebly slow, so givine preference over a few corner cases taht will be fixed vs making every execution extreemly slow ... i take the former
15:51:51 <sdoran> If anything, I'd be more inclined to do what @bcoca suggested and make the C parser a hard requirement.
15:52:20 <mehes-kth> I understand the concern, I was simply expecting that you'd care enough about the corner cases to file the bug yourselves.
15:52:22 <bcoca> even if it limites some cases of how you define a var/entry, its is niche enough that 99% of users won't care
15:52:47 <bcoca> mehes-kth: i would do, but you were the one that discovered it, why i suggested it to you
15:52:48 <sdoran> Especially after all the "Ansible is slow on my Raspberry Pi" issues we got when we added `ansible_builtin_runtime.yml`.
15:53:02 <mehes-kth> LOL
15:53:21 <bcoca> we have good enough relationship with the libyaml/pyyaml folk, it was more of an issue of keeping the credit where it is due, if you don't want to file it, fine, i will
15:53:59 <mehes-kth> I'd prefer that, _exactly_ because you have an existing relationship...
15:54:13 <bcoca> that cuts both ways
15:54:36 <mehes-kth> Like +0 being -1?
15:54:57 <bcoca> well, +0+0+0 == 0 and 'no' is the default
15:55:10 <bcoca> so the bias is you need more possitive than 0/negative
15:55:18 <mehes-kth> I was kidding.
15:56:01 <bcoca> well, its not always clear to all, so i always err on the side of explaining ... done too much ass uming in my life
15:56:06 <mehes-kth> BUT, do let me know if you intend to file the bug; and, whether or not you have a soonish ETA on it.  Otherwise I'll go ahead as agreed.
15:56:43 <bcoca> even if you open bug, i'll comment on it and we can ref existing one in ansible
15:57:21 <mehes-kth> OK.  So, I'll do it ASAP...
15:57:25 <bcoca> thanks
15:57:30 <sdoran> Thank you.
15:57:34 <mehes-kth> np
15:57:50 <bcoca> that is a nasty corner case, we'll probably aslo add to yaml gothcas page JIC
15:58:00 <bcoca> at least till its fixed in origin
15:59:10 <Shrews> ok, now for realsies an open floor.... any other topics?
15:59:53 <bcoca> https://github.com/ansible/ansible/pull/75215 <= what happens when i cannot sleep
16:00:11 <Shrews> rejected. any OTHER topics???
16:00:26 <bcoca> :-(
16:00:31 <Shrews> lol
16:01:03 <Shrews> what are you looking for on that bcoca? reviews? discussion?
16:01:38 <bcoca> eventually, just general 'are you insane' or 'that might be nice'
16:01:41 <sdoran> The better version of `set_fact`, eh?
16:01:44 <bcoca> yep
16:02:13 <bcoca> set_var: scope=host_fact == set_fact: cacheable=false
16:02:18 <bcoca> set_var: scope=host_fact == set_fact: cacheable=true
16:02:23 <sdoran> I think a bit of both. ;)
16:02:24 <bcoca> set_var: scope=host == set_fact: cacheable=false
16:02:45 <bcoca> set_var: scope=play/extras would be the new functionality users have not had till now
16:03:19 <bcoca> also removes teh ability to set a variable named 'scope' ... so i might want to tinker with that
16:04:27 <Shrews> It'd be nice if the PR itself gave a bit more description about the change, IMO. Examples or such. Gleaning that from the code is ick
16:05:08 <bcoca> ok, will add module as doc with examples .. jsut didnt want to go that far in case 'are you insane?' was the first reaction from all
16:05:32 <Shrews> well, we always question your sanity, but the feature itself seems worthy
16:05:48 <bcoca> true .. not related attributes ....
16:07:00 <Shrews> Anything else? Otherwise I'll end the meeting
16:07:33 <Shrews> mehes-kth: thanks for the ping. sorry we started late!
16:08:18 <Shrews> #endmeeting