15:00:16 #startmeeting Ansible Core Public IRC Meeting 15:00:16 Meeting started Thu Sep 2 15:00:16 2021 UTC. 15:00:16 This meeting is logged and archived in a public location. 15:00:16 The chair is shertel. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:16 The meeting name has been set to 'ansible_core_public_irc_meeting' 15:00:19 hello 15:00:28 shertel: Error: Can't start another meeting, one is in progress. 15:00:36 oops 15:00:48 #info agenda https://github.com/ansible/community/issues/628 15:01:16 #chair mkrizek 15:01:16 Current chairs: mkrizek shertel 15:01:25 howdy 15:01:26 I had one for the agenda today if anyone else is around 15:01:31 \o 15:01:32 hello \o 15:01:33 hi! 15:01:35 #topic https://github.com/ansible/ansible/pull/75468 15:02:02 So this is doing two things, 1) fixes ignoring HTTPError exceptions when installing/downloading a collection while getting available versions, which was intended, and 2) handling unexpected errors more flexibly (but with a warning). 15:02:56 I'm wondering for the latter if the warnings are too noisy, or if there are objections to handling unexpected errors similarly 15:03:39 * shertel still needs to add a changelog 15:03:57 what happens if they all fail unexpectedly? Would the error at the end be sufficient? Move the warning to some higher verbosity? Just some thoughts, by way of questions :) 15:04:46 I'm fine with it as is. I know people hate warnings for some reason. I don't have a problem with the warning 15:05:37 I could move the warning to a higher verbosity ouptut for debug purposes. I don't have a strong opinion either, but yes, people don't seem to like warnings 15:06:18 I've approved the PR as is 15:06:26 Cool, thank you! 15:06:37 I am one of those people that hate warnings, but only in situations where I know something will fail and I cannot silence them. 15:07:10 For example, if I know one version is missing from the first server but will be available on the second one, I would like to silence that first warning if possible. 15:08:02 I think that would fall under a HTTPError right? 15:08:03 if a version is missing but the server is functional, that is generally an HTTPError 15:08:11 yeah, so it wouldn't warn 15:08:27 (which has no warning, but will error if the collection couldn't be found on any server) 15:08:46 Then ignore me since this is the exact behavior I would like to see. 15:09:38 if the first server is offline/broken, would you want a warning you can't individually toggle? 15:11:28 would it make sense/be possible for all those `unknown_err`s to be consolidated and printed in one warning instead of each per loop item? 15:11:45 I wouldn't add another individual config toggle. I despise those :) 15:12:48 I think an individual warning per host is best. If anyone else is like me, I'm more likely to read many short warnings, instead of 1 long warning. Plus the count gives you a good idea about multiple problems 15:12:50 sivel: Yeah :) 15:12:51 my 2c 15:14:14 shertel: I do not need individual toggles for things like offline server since all I really care is that my collection got installed. 15:14:31 tadeboro: okay, cool 15:16:21 sivel: by 'per host' do you mean per server, or per collection? The warning is emitted per collection. 15:17:48 I could consolidate the warning to once per server 15:17:56 Well, I guess it's per server per collection right? 15:18:12 yeah 15:18:18 I think it's fine the way it is. No need to overthink it now. If people complain, we can worry later :) 15:18:35 Okay, thanks 15:18:44 #topic open floor 15:18:45 My intent was to say, that the individual warnings will make it more clear in the end 15:19:00 yeah, that makes sense 15:19:15 thanks all for weighing in 15:20:13 Anyone else have something to discuss? If not I'll end in 5 15:20:26 3 .2 .1 15:20:57 :) 15:24:01 #endmeeting