19:03:38 #startmeeting core public irc meeting 19:03:38 Meeting started Tue Nov 2 19:03:38 2021 UTC. 19:03:38 This meeting is logged and archived in a public location. 19:03:38 The chair is bcoca. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 19:03:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:03:38 The meeting name has been set to 'core_public_irc_meeting' 19:03:43 o/ 19:03:47 #topic https://github.com/ansible/ansible/pull/76113 19:04:40 o/ 19:05:02 @goneri ? 19:05:27 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 Hi, sorry I'm on PTO this week. Can we speak about it next weekend instead? 19:05:57 no worries :D 19:05:59 no, not on weekend, but next week 19:06:02 ;-p 19:06:06 enjoy pto 19:06:27 Thanks! 19:06:53 #topic https://github.com/ansible/community/issues/631#issuecomment-955323253 19:07:03 felix, unsure what you are asking, dindt you add these already? 19:07:38 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 I'm not a huge fan of those plugins 19:07:56 also core can more easily guarantee that they don't break in the future ;) 19:08:07 if adding, it would be general to 'plugin_type' not jjust specific ones 19:08:22 bcoca: that would make sense, yes 19:08:43 sivel: is that because you think roles/playbooks should not depend on such information? 19:08:47 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 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 bcoca: unfortuntaely some will definitely abuse them... 19:09:28 yeah, I am basically with bcoca here. I don't think I like the concept 19:09:55 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 having these at runtime ... make it too 'meta' for me 19:10:26 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 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 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 felixfontein: i do not dispute usefulness, its appropriateness 19:11:26 lets take python for example, this is adding a 'detect library' function to eval() 19:11:49 python has try/except for imports :) 19:11:58 not that its not possible todo ... it just does not encourage the right way to do it 19:11:58 (which modules use a lot) 19:12:28 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 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 and plugins were not supposed to 'kill' ansible on missing dep 19:13:12 and we dont use it for 'conditional importing' but for 'nice error reporting to user' .. big diff 19:13:29 and ansible itself already reports 'missing' pluigins 19:13:36 w/o a traceback 19:13:52 play author should not worry about that imho 19:14:05 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 include_role + tasks_from: aws :) 19:15:11 sivel: but how do you make sure that the aws collection(s) you need for these tasks is installed? 19:15:29 you don't. You document it, and let it fail 19:15:48 but in this case, it only fails after starting ordering a certificate 19:16:15 (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 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 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 (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 and i think the downsides are very relevant 19:18:34 i both like it and hate it (like it for my own use, hate it for the bad habbits it enables) 19:18:47 :) 19:18:54 ditto 19:19:14 Like I said, I *almost* did it back in 2.8, but talked myself out of it 19:19:21 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 felixfontein.awesome_plugins_you_cannot_live_without.a_module 19:19:52 ;) 19:19:55 * nitzmahone adds another plug for `sivel.toiletwater` 19:20:00 lol 19:20:35 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 i should create collection with my libvirt stuff .... 19:23:30 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 # topic open floor 19:23:46 #topic open floor 19:29:24 bcoca: sounds fair :) 19:30:35 eventually --syntax-check should list 'missing collections' aside from missing plugins 19:30:54 (though still "best effort" for dynamic stuff unfortunately) 19:31:06 yep, for dynamic stuff it will likely not work :) 19:31:29 (would be madness to expect otherwise) 19:31:51 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 or "we don't know what the heck you want to run here" 19:32:23 ^ exactly what i just said! 19:33:07 also works for - action: module={{action}} args={{myargs}} 19:33:48 well, no new topics, so im going to close meeting, we can continue rest of convo in dev channels 19:33:52 #endmeeting