19:01:26 <bcoca> #startmeeting ansible core public irc meeting 19:01:26 <zodbot> Meeting started Tue Apr 16 19:01:26 2019 UTC. 19:01:26 <zodbot> This meeting is logged and archived in a public location. 19:01:26 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:01:26 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting' 19:01:27 <felixfontein> \o/ 19:01:38 <bcoca> too much ee 19:01:38 * cyberpear waves 19:02:04 <bcoca> #topic https://github.com/ansible/ansible/issues/54412 19:02:15 <nitzmahone> o/ 19:02:46 <bcoca> ^ do we try to enforce 'errors=ignore' on lookups to squelch all underlying errors/warnings from called libs? 19:02:57 <bcoca> shoudl we? 19:03:00 <bcoca> how would we if so? 19:03:29 * bcoca has monkey patch to 'in memory display class' .. but that seems icky 19:05:08 <bcoca> thoughts? musings? 19:05:23 <sivel> I don't think we should try to monkey patch or catch stdout/stderr 19:05:24 <felixfontein> I've never looked at how that works... where is this extra warning coming from? 19:05:37 <nitzmahone> Best effort within reason- we shouldn't generate/propagate on ignore, but we also don't need to hack things to prevent IMO. 19:05:45 <bcoca> underlying function used by more than the lookup 19:05:45 <felixfontein> (and I would prefer no monkey patching either) 19:06:18 <bcoca> but that is this case, the question is 'all cases', so even if we passed option to function to squelch, it would not fix 3rd party libs and/or other api usages in core 19:06:23 <cyberpear> last time, I'd suggested that strict vs ignore could be handled by instead returning Undefined in case of an error, which the user could intercept with default() -- but that doesn't handle what to do with the warnings 19:06:28 <bcoca> nitzmahone: i sign you up for firm -1? 19:06:36 <nitzmahone> Pretty much 19:06:56 <bcoca> im tentative -1 19:07:21 <bcoca> i would like to 'fix this' but i dont see any good way .. unless we move to 'warnings' and import warnings/capture at lookup base 19:07:28 <bcoca> but that is major undertaking 19:07:37 * bcoca we might still want to do that though ... 19:07:45 <felixfontein> I'm for best effort, i.e. don't do black magic to enforce no warnings, but try to remove them if possible (and not too much work) from default lookups 19:08:22 <sivel> that specific warning is coming from `ansible.plugins.lookup.find_file_in_search_path` 19:08:28 <bcoca> so if iread the room correclty, very little support for global solution? 19:08:38 <nitzmahone> Sounds that way 19:09:03 <felixfontein> looks like 19:09:09 <cyberpear> would be nice to fix, but there's probably bigger fish to fry 19:09:16 <nitzmahone> If there are tactical fixes we can make to individual lookups, fine, but yeah, global hacks suck 19:10:29 <bcoca> k, so 'nixing' the global fix and looking for targetted version to this specific issue 19:10:46 <sivel> +1 19:10:55 <bcoca> #topic https://github.com/ansible/community/issues/456#issuecomment-483774086 19:11:25 <bcoca> felixfontein: ^ if you remember HOW noisy this was ... 19:11:40 <felixfontein> yeah, now it's a LOT better :) 19:11:55 <felixfontein> it's still not quiet though ;) 19:12:20 <cyberpear> It's much better than it was, granted. Do I understand correctly that users will always be able to use "invalid" chars if they just change this flag? 19:12:24 <felixfontein> and it is unclear whether having these chars will still be allowed in the future 19:12:48 <bcoca> cyberpear: intention is yes, certainty is 'dunno, future will tell' 19:13:12 <cyberpear> The deprecation message I see seems to indicate it will be supported indefinitely 19:13:38 <cyberpear> I'd like a way to explicitly opt-in to the old behavior and squash the deprecation warning 19:14:00 * nitzmahone not opposed to "extra silent" option there since we have no explicit plans to kill the feature 19:14:08 <cyberpear> either by adding a 'never_silent' option, or changing the default to 'none' which will mean the same thing as 'never' except with a deprecation warning 19:14:15 <nitzmahone> (much as some of us would like to) 19:14:49 <nitzmahone> Though name bikeshed, "never_silent" reads two ways 19:14:54 <bcoca> ^ why i balked to total silence, since keeping it won by 'narrow margin' 19:15:10 <bcoca> 'yolo' 19:16:27 <nitzmahone> "no_really_silent_dont_make_me_get_your_father" 19:17:43 <cyberpear> opt_in_never? 19:18:26 <cyberpear> never_silent seems reasonable to me, and it would be explained in the docs as are the other options 19:18:53 <felixfontein> silent_never? 19:19:10 <cyberpear> +1 silent_never 19:19:48 <nitzmahone> Tough to combine the existing options without confusion, and inventing another one seems weird, so I can live with either of those I guess 19:20:11 <bcoca> ignore already exists 19:20:14 <bcoca> 'ignore' 19:20:27 <cyberpear> rename the existing 'silent' to 'silent_always'? 19:20:41 <cyberpear> so never, always, silent_never, silent_always? 19:20:49 <bcoca> no 19:20:51 <felixfontein> bcoca: ignore still outputs a warning 19:21:01 <bcoca> felixfontein: but that can change 19:21:11 <bcoca> better than ^ those options above 19:21:29 <cyberpear> 'ignore' is fine w/ me 19:21:38 <bcoca> /ignore cyberpear 19:21:45 <nitzmahone> Yeah, if we're ok ditching the warning, that WFM too 19:21:52 <nitzmahone> lol 19:21:56 <bcoca> anyone against ditching teh warning? 19:21:59 <felixfontein> 'ignore' sounds a bit strange as an option to "transform invalid group chars", when trying to read it as a natural language sentence 19:22:07 <bcoca> i was -0.5 due to people freaking about it 19:23:13 <felixfontein> doesn't look like someone really wants the warning 19:23:47 <bcoca> warning is there cause if not, we get flood of tickets complaining 19:24:14 <bcoca> so we tend to 'over warn' ... and to be fair, people in this chat right now are not good representation of skill set and engagement most useres have 19:24:45 <felixfontein> that I think we can agree on :) 19:24:45 <bcoca> its very skewed to the 'high/high' corner, while users that WANT/DEMAND the warnings are mostly low/low part of the chart 19:25:53 <felixfontein> but we're just talking about removing the warning when the user explicitly changes the default to 'ignore', right? 19:26:10 <felixfontein> I mean, for me the warning can stay there if the user doesn't change the default 19:26:40 <cyberpear> felixfontein: yes 19:26:54 <bcoca> warning STAYS with the default 19:26:56 <nitzmahone> The one weird case there might be Tower 19:27:06 <nitzmahone> Don't they set to ignore? 19:27:13 <bcoca> nitzmahone: no 19:27:27 <nitzmahone> Ok... So long as that one's covered, I'm good. 19:27:31 <bcoca> ignore is not a 'public' option .. till felixfontein let it out of the bag 19:27:43 <felixfontein> heh, *you* added it, not me :) 19:27:55 <bcoca> remind me next time you beg me for it ... 19:28:03 <bcoca> :-p 19:28:07 <felixfontein> :D 19:30:13 <felixfontein> ok, so 'ignore' without a warning it is? or is the name of the option value still open? 19:30:34 <nitzmahone> Sounds good to me 19:30:39 <bcoca> or we can bikeshed on names for rest of meeting .. 19:30:57 <nitzmahone> "Steve" 19:31:01 <cyberpear> let's "open floor" -- klaas wanted to bring something up 19:31:24 <felixfontein> who will implement it? 19:31:36 <bcoca> #topic https://github.com/ansible/ansibullbot/issues/1183#issuecomment-478001863 19:31:43 <bcoca> @gundalow ? 19:32:53 <felixfontein> I was assuming that the information which is in the plugins is already being used... and found out it isn't after several (failed) tries 19:33:13 <bcoca> k, soo. my take, you can do as modules .. set it in docs in plugin and/or botmeta, docs allow 'author' field .. i would prefer botmeta since it has little to do with execution and mostly to do with commit privs 19:33:28 <bcoca> felixfontein: hmm, that is bug in bot, its supposed to look at both 19:33:38 <bcoca> with botmeta > embeded docs 19:35:00 <felixfontein> i.e. like for modules? 19:35:03 <bcoca> so no diff opionoins on how it should work? just that we need to open bug on ansibot 19:35:11 <bcoca> felixfontein: yep, its basically same system 19:35:26 <gundalow> bcoca: hey 19:35:29 <cyberpear> (same issue for other plugin types connection, lookup, etc) 19:35:30 <felixfontein> or feature request, depending on how you look at it ;) 19:35:44 <felixfontein> cyberpear: I thought this was about all kind of plugins 19:35:57 <cyberpear> just clarifying, since the bug linked only lists one kind 19:35:59 <bcoca> gundalow: so we all agree, you need to fix ansibullbot (what you get for being late!) 19:36:15 <bcoca> cyberpear: agreed, all 'documentable plugin types' .. which has a specific list/constant 19:36:54 <gundalow> bcoca: so Metadata fromm he plugins themselves? 19:37:33 <felixfontein> gundalow: yes, with botmeta overriding them if present 19:38:00 <bcoca> gundalow: both 19:38:10 <cyberpear> same as for modules is best, I think 19:38:14 <bcoca> gundalow: and author is not in metadat but in 'documentation.author' list 19:38:28 <bcoca> same as modules 19:38:36 <gundalow> #agreed Plugins Metadata should be the same as modules ie 1) use plugins' ANSIBLE_METADATA 2) fall back to BOTMETA.yml 19:38:40 <gundalow> Thanks 19:38:51 <bcoca> #topic open floor 19:39:13 <bcoca> @gundalownot ansible_metadata, DOCUMENTATION, metadata has no authors 19:39:18 <bcoca> only support 19:39:29 <bcoca> most plugins do have author, but not support/metadata 19:39:39 <bcoca> ^ @gundalow 19:39:51 <klaas> if I create a PR to change the default ssh options to include ServerAliveInterval, would that have a chance of getting merged or would that be something you would not want to set as default? The problem that lead me to propose this change is that a task can't hang for long (hours) if the target crashes or loses network connectivity with default ssh 19:39:51 <klaas> options. 19:40:18 <gundalow> bcoca: ACK 19:40:40 <gundalow> #info Call for Papers for Ansible Fest is open https://www.ansible.com/ansiblefest 19:40:54 <cyberpear> I'm in favor of the change proposed by klaas -- this issue arises whenever a task take more than the SSH timeout set to a short interval on security-hardened systems 19:41:24 <nitzmahone> That option's been around for a long time, so probably ok from a supportability perspective 19:41:48 <bcoca> why not add to ansible_ssh_args? 19:42:22 <bcoca> also, users deal with a lot of 'laggy systems' be it cloud or remote DCs 19:42:34 <bcoca> i prefer to leave it configurable (which it already is) 19:42:51 <bcoca> and let ssh system defaults work (ssh_config can also set this sytem wide) 19:43:00 <bcoca> just like sshd_config can set on server side 19:43:30 <bcoca> i prefer not to touch 'defaults' w/o a compeling reason taht works for 90%+ of users 19:43:31 <klaas> bcoca it is configureable, you can just edit multiple configs -- I was just curious if that is somehing you would consider could/should go into default ansible config 19:44:00 <bcoca> klaas: i would say it should be 'default ssh config' ... i dont think ansible should deviate from that unless its really needed 19:44:05 <sivel> I would be -1 on adding ServerAliveInterval to default ssh options 19:44:17 <sivel> Our default options should be pretty minimal 19:44:21 <bcoca> tmrow ssh changes default to 20s ... we would be stuck with our default 19:44:47 <sivel> I have a lot of customization done to my ssh client config that could be disrupted by adding such new defaults 19:44:54 <bcoca> we are already too intrusive for my taste with ssh connections ... i woudl take back 1/2 of stuff we currently pass 19:45:09 <nitzmahone> ditto 19:45:19 <sdoran> I agree with that. Leave most of the config to the underlying tool. 19:45:28 <sdoran> That gives users the most flexibility to manage their connections. 19:45:45 <bcoca> most of our issues with people and 'unreachable' hosts is cause of the 'defaults' we impose already, causing issues from their 'non ansible ssh usage' 19:46:00 <bcoca> adding more to that is not something i want to do 19:46:40 <bcoca> klaas: i dont disagree with that being a good default, i just dont think we should do taht in ansible itself 19:48:58 <cyberpear> bcoca: klaas would it make sense to add this in the docs somewhere to workaround timeout issues? 19:49:07 <bcoca> faq entry is fine with me 19:49:28 <bcoca> even 'note' on ssh plugin 19:49:38 <klaas> yeah I can look if I can write a small docs pr for the general problem somewhere 19:50:04 <bcoca> k, will wait on that PR 19:50:08 <bcoca> anything else? 19:50:52 <sivel> I'll be merging the switch to argparse PR early next week 19:50:57 <sivel> just a statement :) 19:51:08 * cyberpear celebrates 19:51:58 <bcoca> im fine either way, seems same ammount of work to use than optparse 19:52:03 <felixfontein> who wants to implement the 'ignore' option for TRANSFORM_INVALID_GROUP_CHARS? 19:52:16 <bcoca> want? or will? 19:52:19 <felixfontein> both ;) 19:52:30 <bcoca> i will, i dont wanna, but i will 19:52:50 <felixfontein> will it make it into 2.8.0? 19:53:11 <bcoca> possibly, depends if gets considerd as 'new feature' 19:53:30 <felixfontein> I would call it a bugfix, since the feature was already mostly there :) 19:54:12 <bcoca> i have had that discussion many times, never ends up on the side i expect 19:54:27 <felixfontein> hehe 19:54:39 <bcoca> also RM just went on PTO 19:56:08 <felixfontein> when will he be back? 19:57:55 <bcoca> idk 19:58:40 <nitzmahone> presumably before RC1 ;) 19:59:17 <bcoca> werent you taking over? 19:59:37 * bcoca should really stay awake during meetings 19:59:51 <felixfontein> meeting != night ;) 20:00:08 <bcoca> i refuse to adopt to a timezone! 20:00:11 <bcoca> or solar cycle 20:00:22 <bcoca> k, not any real topic so ... 20:00:26 <bcoca> #endmeeting