19:03:38 <bcoca> #startmeeting core public irc meeting
19:03:38 <zodbot> Meeting started Tue Nov  2 19:03:38 2021 UTC.
19:03:38 <zodbot> This meeting is logged and archived in a public location.
19:03:38 <zodbot> The chair is bcoca. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:03:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:03:38 <zodbot> The meeting name has been set to 'core_public_irc_meeting'
19:03:43 <nitzmahone> o/
19:03:47 <bcoca> #topic https://github.com/ansible/ansible/pull/76113
19:04:40 <felixfontein> o/
19:05:02 <bcoca> @goneri ?
19:05:27 <nitzmahone> I'm still -1 for this in core until we've got proper stateful workers/connections everywhere to be able to manage it correctly. Look at recent bugs on it and you can see some of the reasons that doing it "unmanaged" causes problems...
19:05:43 <Goneri> Hi, sorry I'm on PTO this week. Can we speak about it next weekend instead?
19:05:57 <nitzmahone> no worries :D
19:05:59 <bcoca> no, not on weekend, but next week
19:06:02 <bcoca> ;-p
19:06:06 <bcoca> enjoy pto
19:06:27 <Goneri> Thanks!
19:06:53 <bcoca> #topic https://github.com/ansible/community/issues/631#issuecomment-955323253
19:07:03 <bcoca> felix, unsure what you are asking, dindt you add these already?
19:07:38 <felixfontein> yes, but I added them to community.general. it would be nice if they also exist in core, so that one does not have to install a collection like community.general to get access to these
19:07:43 <sivel> I'm not a huge fan of those plugins
19:07:56 <felixfontein> also core can more easily guarantee that they don't break in the future ;)
19:08:07 <bcoca> if adding, it would be general to 'plugin_type' not jjust specific ones
19:08:22 <felixfontein> bcoca: that would make sense, yes
19:08:43 <felixfontein> sivel: is that because you think roles/playbooks should not depend on such information?
19:08:47 <nitzmahone> I was really close to adding some form of the actions/lookups that the core tests use internally to core itself in the original collections feature, but I wasn't happy with the UX for them.
19:08:49 <bcoca> but my worry is that it encourages 'meta plays' that will conditionally create tasks  ... which does very little for readability/auditability/simplicity
19:09:24 <felixfontein> bcoca: unfortuntaely some will definitely abuse them...
19:09:28 <sivel> yeah, I am basically with bcoca here. I don't think I like the concept
19:09:55 <bcoca> i would say these things are required on install and that --syntax-check should be 'normal' way to detect, play/role should not be that 'self concious'
19:10:14 <bcoca> having these at runtime ... make it too 'meta' for me
19:10:26 <felixfontein> I personally find them very useful for optional dependencies of a collection (or role): you can make sure that dependencies are around (when features are asked for by the user which need these) before everything is half-way set up and potentially expensive objects have been created
19:10:32 <nitzmahone> I too was worried about the potential for abuse/misuse- it's definitely handy for things like pre-flight checks on more dynamic content, but yes, could definitely be abused for other nefarious purposes :D
19:10:42 <sivel> A playbook author should just declare what it wants and away it goes. I'm not a fan of adding introspection capability like this
19:10:44 <bcoca> felixfontein: i do not dispute usefulness, its appropriateness
19:11:26 <bcoca> lets take python for example, this is adding a 'detect library' function to eval()
19:11:49 <felixfontein> python has try/except for imports :)
19:11:58 <bcoca> not that its not possible todo ... it just does not encourage the right way to do it
19:11:58 <felixfontein> (which modules use a lot)
19:12:28 <sivel> it's also not exactly clear on what a set of tasks would accomplish in any reasonable manner, as it's hugely dependent on a users install preferences or availability or lack of functionality
19:12:31 <bcoca> yes, cause modules lack one very important thing ... a way to declare dependencies on install (well, collections /a-builder are a solution to that)
19:12:44 <bcoca> and plugins were not supposed to 'kill' ansible on missing dep
19:13:12 <bcoca> and we dont use it for 'conditional importing' but for 'nice error reporting to user' .. big diff
19:13:29 <bcoca> and ansible itself already reports 'missing' pluigins
19:13:36 <bcoca> w/o a traceback
19:13:52 <bcoca> play author should not worry about that imho
19:14:05 <felixfontein> sivel: in my case, I allow to chose from a set of DNS providers in a role, and I don't want to force installation of all these collections (since most users will need at most one of these). (also there's one DNS provider where you need to install a module in library/, and there's no way to handle that with dependencies if you don't want to vendor that module)
19:14:33 <sivel> include_role + tasks_from: aws :)
19:15:11 <felixfontein> sivel: but how do you make sure that the aws collection(s) you need for these tasks is installed?
19:15:29 <sivel> you don't. You document it, and let it fail
19:15:48 <felixfontein> but in this case, it only fails after starting ordering a certificate
19:16:15 <felixfontein> (which depending on the CA might cost money - fortunately no CA currently existing seems to charge for creating orders that are not fulfilled, but you never know ;) )
19:17:19 <felixfontein> I'm fine with just having these plugins in community.general, I personally think they should be part of core, but if you don't want that, I fully understand :)
19:17:43 <bcoca> if well documented, at that point i would make user responsible, you went extra 10 and created the detection, that is fine, but i don't think it is common enough case to justify core inclusion
19:18:03 <felixfontein> (also I already got similar feedback from community members... some really like this, some don't like it for basically the same reasons)
19:18:06 <bcoca> and i think the downsides are very relevant
19:18:34 <bcoca> i both like it and hate it (like it for my own use, hate it for the bad habbits it enables)
19:18:47 <felixfontein> :)
19:18:54 <nitzmahone> ditto
19:19:14 <nitzmahone> Like I said, I *almost* did it back in 2.8, but talked myself out of it
19:19:21 <bcoca> they are neat tools, i would just keep them in the 'masterful expert' section of the toolshed and not with the noobie tools
19:19:29 <sivel> felixfontein.awesome_plugins_you_cannot_live_without.a_module
19:19:52 <sivel> ;)
19:19:55 * nitzmahone adds another plug for `sivel.toiletwater`
19:20:00 <felixfontein> lol
19:20:35 <felixfontein> I do have felixfontein.tools, but I'm trying to empty it (by adding the interesting parts somewhere else); otherwise I'd probably add it in there
19:22:28 <bcoca> i should create collection with my libvirt stuff ....
19:23:30 <bcoca> k, sorry to say but seems there is mostly quorum against inclusion, the tools are nifty .. just not good to have something like that in core and peopl;e starting to create pbs that rely on it
19:23:37 <bcoca> # topic open floor
19:23:46 <bcoca> #topic open floor
19:29:24 <felixfontein> bcoca: sounds fair :)
19:30:35 <bcoca> eventually --syntax-check should list 'missing collections' aside from missing plugins
19:30:54 <nitzmahone> (though still "best effort" for dynamic stuff unfortunately)
19:31:06 <felixfontein> yep, for dynamic stuff it will likely not work :)
19:31:29 <felixfontein> (would be madness to expect otherwise)
19:31:51 <bcoca> i have plans for that, but there will still be cases that will be 'include was skipped due to missing enough data to successfully template values'
19:32:11 <nitzmahone> or "we don't know what the heck you want to run here"
19:32:23 <bcoca> ^ exactly what i just said!
19:33:07 <bcoca> also works for - action: module={{action}} args={{myargs}}
19:33:48 <bcoca> well, no new topics, so im going to close meeting, we can continue rest of convo in dev channels
19:33:52 <bcoca> #endmeeting