19:06:08 <bcoca> #startmeeting ansible core public irc meeting
19:06:08 <zodbot> Meeting started Tue Oct  6 19:06:08 2020 UTC.
19:06:08 <zodbot> This meeting is logged and archived in a public location.
19:06:08 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:06:08 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:06:23 <felixfontein> bcoca: fine for me, just saw them, thanks!
19:06:23 <bcoca> #note before we start, next week there won't be any meetings due to ansible fest
19:06:34 <bcoca> #topic open floor
19:07:23 <felixfontein> bcoca: putting the result in a constant level constant (or class level constant, if its in a class) sounds good to me, I'll do that
19:08:11 <felixfontein> aminvakil just put https://github.com/ansible/ansible/pull/71172 on the agenda
19:08:48 <bcoca> #topic 71172
19:09:11 <sdoran> There is still debate on whether or not we _want_ FQCN for built ins in the docs.
19:09:17 <sdoran> But that's a separate and ongoing debate.
19:09:31 <aminvakil> I'm confused about my PR state.
19:09:41 <bcoca> well, we decided no in previous meeting, but it got decided 'yes' in docs meeting
19:10:02 <felixfontein> sdoran: that's an interesting debate as well, but I think no matter what's the outcome, FQCN should also work for ansible.builtin :)
19:10:42 <bcoca> felixfontein: yes, but it doesnt ...
19:10:43 <aminvakil> I don't know if implenting try-restart is worthy or not, also how to handle if reloaded-or-restarted is going to be added to systemd module. https://github.com/ansible/ansible/issues/71969
19:10:55 <bcoca> aminvakil: i still stand on my first comment
19:10:56 <sdoran> felixfontein: That is easier said than done. Hence why it's an issue.
19:10:59 <felixfontein> bcoca: it works in *most* cases, just not in all because of hard-coded names :)
19:11:06 <sdoran> Yup.
19:11:18 <bcoca> felixfontein: not just that, there are also corner cases on how plugin loader works with action/module interactions
19:11:35 <bcoca> see the bug about 'command' being overloaded in networking colleciton AND builtin
19:11:35 <felixfontein> (I hope my PR fixes most of them)
19:11:52 <bcoca> yours fixes the 'hardcoded name matching' ... there are plenty of others
19:11:59 <aminvakil> bcoca: now I agree with you, it isn't necessary and can be handled as your comment, so should I just close it?
19:12:25 <bcoca> others disagree with me, dont close it on just my opinion
19:12:26 <felixfontein> bcoca: true
19:12:47 <bcoca> felixfontein: the problem is we are also updating the docs to reflect fqcn always .. even examples that dont currently work
19:13:45 <bcoca> if we wait till we fix 'all da cases' .. then we can talk about that, ubt also some in core feel like keeping the short names for builtins is also better, not having to force peopel to add ansible./builtin in collecitons: also it bypasses library/ and ajacent behaviour
19:13:54 <bcoca> so its not really backwards compatible
19:14:53 <bcoca> k, l;etws stop mixing topics
19:15:22 <bcoca> back to systemd (yes .. i dont wanna either) ... can we get votes for/against merging the PR that adds conditinoal restarts?
19:16:27 <aminvakil> i'm against my PR as well:)
19:16:33 <felixfontein> bcoca: +1 for not mixing topics ;)
19:16:41 <felixfontein> (I'm also very guilty for that...)
19:16:41 <shertel> the code looks fine but I don't have an opinion. Kinda -1 if the author doesn't think it's necessary.
19:17:49 <bcoca> anyone else?
19:19:15 <sdoran> It's really the systmed options that muddy things.
19:19:40 <sdoran> I feel like allowing one means we'll eventually have to allow them all. And the names are just terrible nomatter how you slice it.
19:19:41 <bcoca> aminvakil: k, i think you got an answer, thanks for the effort, really feel bad on all the bikeshedding we made you go through
19:20:11 <bcoca> #topic ansbile.builtin.include vs include
19:20:40 <bcoca> felixfontein:  my guess is that docs wants it for uniformity, but at least for now, since it doesnt work, i would stop rewriting all examples to fqcn
19:20:44 <aminvakil> bcoca: ok thanks!
19:21:11 <felixfontein> bcoca: I think you're right on both accounts
19:22:15 <felixfontein> I personally think it is a good idea to use the ansible.bulitin. prefix, because we're suggesting to use FQCN in general (uniformity), and because it avoids problems with collections using the same shortnames when the `collections:` keyword comes into play
19:22:52 <bcoca> felixfontein: but people are lazy and want to type less, probalby only using fqcn to disambiguate
19:23:17 <bcoca> its an issue we pointed out on network collections since 90% of modules use same naming pattern and conflicting short names
19:23:28 <sdoran> I'm in favor of FQCNs being reserved for things in collections outside of anible-core. Builtins can and should continue to use just the plugin/filter name.
19:23:30 <bcoca> but its also rare you use multiple network collections in same play
19:23:35 <felixfontein> bcoca: I fully agree...
19:23:51 <sdoran> I think we should deprecate `collections:` long term. It just creates too much room for collision.
19:24:16 <felixfontein> sdoran: with `collections:` gone I agree that shortnames for builtin stuff only are ok
19:24:49 <sdoran> We need `collections:` to ease the transition. But long term it should go away and FQCNs should be required.
19:25:46 <shertel> I agree with that
19:25:49 <bcoca> sdoran: and flaming pitchforks will appear for those that complain about too much typing
19:26:12 * bcoca points everyone to the 'this' proposal for similar issues
19:26:27 <Shrews> we could go the java route and add a `namespace` block...   /me hides
19:26:37 <sdoran> Hopefully someone will have created a translation tool by then.
19:26:40 <felixfontein> btw, when talking about include_vars, it would be nice to be able to do what include_vars does in custom action plugins. I wanted to write an action plugins which loads vars from sops-encrypted files, and I only was able to do it properly by setting `self._task.action = 'include_vars'`...
19:26:46 <jborean93> Shrews: welcome to the collections keyword
19:26:50 <bcoca> Shrews: we did, that is what 'collections' is
19:26:55 * sdoran has no plans to write/share such a thing
19:26:57 <bcoca> jborean93: jinx
19:27:13 <felixfontein> bcoca: the `this` proposal is also about the registered variable not leaking into other tasks
19:27:13 <Shrews> i meant more intrusive... but nm. i similarly hate java
19:27:49 <bcoca> felixfontein: no, its hardcoded for a reason, mostly cause we can avoid sanatizing everything from action plugins, just from modules, if we do that the plugin separation/security would need to be a lot more intrusive and would have huge performance impliciation
19:27:51 <felixfontein> Shrews: I wish java would deprecate wildcard imports. without them, there are no collisions and it is fine :)
19:28:26 <bcoca> felixfontein: and just as many java devs will scream that now they have to make expliciit imports of everything
19:28:29 <felixfontein> bcoca: I would love to not have to create a plugin for that, but then I'd need vault plugins :)
19:28:42 <felixfontein> bcoca: IDEs usually do the imports
19:28:44 <bcoca> felixfontein: you kindof have em already
19:28:54 <bcoca> vars plugins can handle vaults
19:29:00 <bcoca> just not ansible-vault
19:29:00 <felixfontein> (I'm doing a lot of $JOB programming in java :) )
19:29:22 <bcoca> felixfontein: nvi does not create imports automatically!!!
19:29:24 <felixfontein> bcoca: yes, but include_vars does not use vars plugins
19:29:35 <bcoca> true
19:29:38 <felixfontein> bcoca: it's not an IDE
19:29:52 <bcoca> felixfontein: depends on whom you ask
19:30:03 <bcoca> others state that EMACS is not an OS ...
19:30:08 <felixfontein> true
19:30:17 <felixfontein> one needs to define IDE first I guess
19:30:28 <felixfontein> but that's another bikeshed to paint...
19:31:10 <felixfontein> btw, another off-topic: https://github.com/ansible/ansible/pull/71734 (validate-plugins) is no longer a WIP and tests pass in ansible/ansible
19:31:17 <bcoca> woot
19:31:21 <shertel> what does include_vars get you that a vars plugin couldn't?
19:31:22 <felixfontein> (no longer a wip from my side :) )
19:31:58 <bcoca> shertel: used in play, diff precedence
19:32:12 <felixfontein> shertel: (1) you can include dynamically, (2) you can include huge vars files locally without having to load them for the whole playbook (which can improve performance)
19:33:57 <bcoca> felixfontein: you can do that in vars plugin, just not activate it 'per play'
19:35:34 <felixfontein> bcoca: how do you mean that?
19:36:07 <bcoca> the plugin itself can decide to give back data or not, just need to define conditions AND base them on data the plugin can get
19:36:35 <bcoca> the plugins get executed per group/host, optionally at invenotry time, task time or both
19:38:03 <shertel> in 2.10+ anyway
19:38:03 <felixfontein> bcoca: hmm, sounds hacky
19:38:09 <bcoca> hmm, we can continue this in devel, at this point we are not deciding anything for this meeting, so going to close
19:38:14 <bcoca> felixfontein: i dont pretend its not
19:38:18 <bcoca> #endmeeting