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