15:00:31 <bcoca> #startmeeting ansible core irc meeting 15:00:31 <zodbot> Meeting started Thu Jan 31 15:00:31 2019 UTC. 15:00:31 <zodbot> This meeting is logged and archived in a public location. 15:00:31 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:31 <zodbot> The meeting name has been set to 'ansible_core_irc_meeting' 15:01:45 * gundalow waves 15:05:20 <bcoca> damn, forgot to make feb ticket, so jan one is still in play 15:05:43 <bcoca> @dag? 15:06:12 <bcoca> #topic https://github.com/ansible/ansible/issues/15484 15:08:12 <bcoca> so handler/run_once interaction, unsure how this should work, was looking for opinions from the community 15:08:32 <dag> yes 15:09:14 <bcoca> part of it is due to run_once misnomer .. really 'run_on_first_update_all_hosts_with_return' 15:09:19 <bcoca> which includes facts 15:09:31 <bcoca> run_one_for_all 15:09:51 <dag> one_to_run_them_all 15:09:59 <bcoca> the_ring 15:10:14 <dag> :) 15:11:17 <dag> I think we're alone now 15:11:55 * bcoca brings out D&D dice 15:12:03 * dag plays Tiffany 15:12:09 <bcoca> k, w/o quorum not really worth discussing anything 15:12:34 <dag> This is the perfect time to merge all my PRs :-) 15:12:40 <bcoca> and mine! 15:12:57 <dag> All attendance were in favor! 15:13:02 <dag> attendants 15:13:15 <gundalow> motion carried 15:13:24 <alikins> requiring run_once on the handler ala https://github.com/ansible/ansible/issues/15484#issuecomment-213642704 seems ok 15:14:11 * dag still has his doubts about run_once, and until that is fixed, I think we should refrain from expanding a misunderstood directive 15:14:38 <alikins> which I guess you could think of as 'when this handler runs, it should "disconnect" itself' 15:15:01 <alikins> dag: yeah, good point 15:15:28 <bcoca> he, agreed on that point 15:15:43 <bcoca> but i can see that you want handler to behave differently if original task had run_once vs not 15:16:09 <bcoca> so making handler run_once might not be a fix since you may use same handler from 'run_once: false' tasks 15:16:27 * dag is referring to this: https://github.com/ansible/ansible/issues/19966 15:16:33 <dag> bcoca: agreed 15:16:35 <bcoca> not sure this is enhancing run_once as much as 'defining' how it should behave in relation to handlers 15:17:10 <bcoca> dag: bypass_host_loop .. which ends up being a 'hardcoded' versino of run_once ... 15:17:50 <bcoca> which makes sense for stuff like add_host/group_by ... pause i would argue should have been an 'option' for the action, but that was done long before i even realized we had a pause module 15:17:54 <dag> bcoca: I know, has been beaten to death by now :) 15:18:16 <dag> and we don't have quorum just yet 15:18:21 <bcoca> resurrected, beaten to death again, revived, beaten to pulp 15:19:16 <dag> :) 15:23:19 <bcoca> unsure what to do, either wait for more people or just have the 4 of us decide? 15:26:29 <alikins> decide not to decide 15:27:20 <alikins> don't 'pause' the meeting attempting to 'run_once' each agenda item ;-> 15:27:38 <bcoca> alikins++ for reentrant sarcasm 15:27:56 <bcoca> #endmeeting