15:04:42 <sdoran> #startmeeting Ansible Core Public IRC Meeting https://github.com/ansible/community/issues/516
15:04:42 <zodbot> Meeting started Thu Jan 23 15:04:42 2020 UTC.
15:04:42 <zodbot> This meeting is logged and archived in a public location.
15:04:42 <zodbot> The chair is sdoran. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:42 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting_https://github.com/ansible/community/issues/516'
15:05:15 <sdoran> Hello everyone. Thanks for attending.
15:05:25 <sdoran> Still trying to get a few more Core folks to join.
15:05:25 <felixfontein> hi!
15:05:57 <sdoran> 👋
15:07:59 <sdoran> #topic https://github.com/ansible/ansible/pull/62662
15:08:08 <sdoran> Going through the holdover topics first.
15:08:13 <sdoran> You're up, jtyr
15:08:59 <jtyr> I have done the requested changes so just wanted to ask if somebody could review it.
15:09:29 <jtyr> I can see that the branch is out of sync atm ... will rebase and push
15:09:46 <sdoran> For this one, the only outstanding issue was to write `pytest` style tests.
15:09:52 <sdoran> That's what we prefer for net-new tests.
15:10:17 <shertel> \o
15:10:25 <sdoran> #chair shertel
15:10:25 <zodbot> Current chairs: sdoran shertel
15:10:45 <jtyr> ;o/
15:12:56 <sdoran> Ok, so #62662 just needs a rebase and minor change to test format. I'll be happy to merge it once those things are done.
15:13:06 <shertel> It looks good at a glance besides the tests
15:13:13 <shertel> +1
15:13:30 <sdoran> #topic https://github.com/ansible/ansible/pull/65799
15:14:27 <bcoca> variables should never be none there
15:14:35 <bcoca> also does not seem to do what the title says it does
15:14:40 <jtyr> the tests are actually in devel, so I'm just rebasing my changes on top ...
15:14:48 <sdoran> <nod>
15:15:18 <bcoca> the default is still ''
15:15:28 <bcoca> am i missing something?
15:15:53 <jtyr> bcoca: I didn't rebase yet ...
15:16:53 <bcoca> even if you do, wouldnt that mean the change the PR states to make, is already in devel?
15:17:06 <bcoca> <= confused
15:17:42 <shertel> yeah, just docs and tests on it?
15:17:45 <bcoca> not against the changes, they just seem mostly docs + style + adding test
15:17:56 <bcoca> just dont match subject
15:18:14 <sdoran> For #62622, we asked that it just be a docs change rather than a change in behavior, per previous meeting discussion.
15:18:20 <jtyr> bcoca: check it now ... it changes only documentation and examples
15:19:46 <bcoca> i get that, just alter the subject, it is misleading
15:20:20 <bcoca> ah nvmd, you do actually change the default, but you changed the signature
15:20:38 <jtyr> just pushed another update ... forgot to leave there the 'default' option ...
15:21:54 <bcoca> and you leave the example using |default, but still add the default option/
15:23:38 <jtyr> yeah, let me fix that ...
15:24:20 <jtyr> should be good now
15:24:59 <bcoca> still, i thought we agreed to just change the docs , not to add this feature since |default already exists
15:25:16 <bcoca> or am i misremembering prevoious meetings?
15:25:19 <sdoran> Yup, I think that's how it is now.
15:25:22 <sdoran> Real time coding! :)
15:25:48 <bcoca> i would table this for later, not really meant to do coding in this meeting
15:26:04 <jtyr> hehe ... sorry, for the confusion ... was diffing against wrong commit ... it should be all fixed now
15:26:38 <sdoran> jtyr: So what would you like to discuss on #65799?
15:27:07 <bcoca> ah, so reading , yes we said we would take docs update, but not the behaviour change, so i would go back to first version you showed, just change subject on pr to avoid confusion
15:28:01 <jtyr> well .. I have discused it a little bit with bcoca last year and he said that such thing might not be added to the core any more which completely ruined my Christmas ... so I just wanted to know if you would consider such feature or not  (new year, now opinion? - I really hope so) ...
15:29:59 <sdoran> This lookup takes a list of files and stores all the variables in those files inside another variable?
15:30:46 <jtyr> yes, files or a directory...
15:31:10 <jtyr> or better to say ... directory and allows to filter files in that directory ...
15:31:20 <sdoran> Interesting.
15:31:35 <sdoran> Anyone else have thoughts about this new lookup plugin?
15:31:50 <jtyr> it basically concatenate YAML files and compose single variable out of it ...
15:34:18 <jtyr> I'm personally using it to create list of VM definitions which I use to create VMs on VMware ... each VM definition is in separate file and this lookup composes single variable out of all the files ...
15:35:00 <jtyr> using this role for that: https://github.com/jtyr/ansible-vmware_vm_provisioning
15:35:35 <jtyr> the lookup plugin is used somewhere in group_vars ...
15:36:11 <sdoran> I understand the use case. It does seem useful. We just have to balance new features and the inherent support cost (in time and energy) with community demand for the new feature.
15:36:48 <sdoran> I don't see many in the community asking for this feature.
15:37:15 <felixfontein> it might make more sense to offer it via a collection to people who are interested
15:37:25 <jtyr> people might use it once it's available ... ;o)
15:38:04 <jtyr> "collections" argument again ...
15:38:06 <sdoran> Yeah, the classic chicken and egg situation.
15:38:20 <jtyr> collections require users to download something extra ...
15:38:20 <sivel> to state a goal, regardless if it merges to ansible/ansible, it wont be there long
15:38:44 <sivel> My goal is within about 3 weeks, everything will be beginning the migration to collections
15:38:48 <sdoran> #chair bcoca sivel
15:38:49 <zodbot> Current chairs: bcoca sdoran shertel sivel
15:38:49 <felixfontein> I guess the main difference is whether it's in the "all batteries included" distribution or not
15:38:50 <jtyr> I  don't like collections ... it's a pain in restricted areas ...
15:38:57 <bcoca> include_vars + dir + name doesnt already do same?
15:39:12 <jtyr> nop
15:39:14 <sivel> at which point, if it is accepted, it would go to github.com/ansible-collections/dumping_ground
15:39:22 <jtyr> I need all the files to be in one variable
15:39:30 <bcoca> jtyr: it wont stay in core even if merged
15:39:31 <sivel> So I'm not in any hurry to accept any new modules/plugins right now
15:39:44 <bcoca> jtyr that is what name does for include_vars
15:39:53 <bcoca> actually, you could do same with file lookup and lop
15:40:53 <sdoran> Alright, we're going to move on to the next topic.
15:41:11 <sdoran> #topic https://github.com/ansible/ansible/pull/65801
15:41:22 <jtyr> include_vars is a module ... lookup plugin allows you to do it directly in group_vars
15:41:34 <jtyr> bcoca: ^^^
15:42:00 <bcoca> map + file lookup
15:43:55 <jtyr> bcoca: can you use patters in file loopkup?
15:44:05 <bcoca> patters?
15:44:15 <jtyr> *.yaml
15:44:55 <bcoca> ah, fileglob, find task, again i see this as redundant
15:45:03 <sdoran> This new CSV callback plugin probably falls into the same category as the last plugin we discussed: while useful, it probably doesn't make much sense to merge it at this point in time.
15:45:24 <jtyr> bcoca: find is a module ... you cannot call module from group_vars ...
15:45:42 <bcoca> doesnt matter, you only need to call before you use the var
15:45:47 <bcoca> definition does not imply resolution
15:46:19 <jtyr> it complicates it if you have to do it in a task ...
15:46:22 <sivel> one thing we have previously mentioned, is we don't intend on adding functionality to meet every persons needs, especially when the result can be achieved via other means, regardless of whether it fits a persons views
15:46:48 <jtyr> I get it
15:47:26 <sdoran> I will concede that the interface of a single lookup plugin is much better than a combination of several plugins and data manipulation in a playbook.
15:47:35 <jtyr> but that you could say about 99.9% of modules ... because everything can be done via shell/copy/fetch modules ...
15:48:06 <sdoran> But we can't take on everything, unfortunately.
15:48:13 <bcoca> sdoran: agreed, just not seeing a big need for this and it is easy to end up with a slew of 'easier/grouped' functionality plugins
15:48:32 <bcoca> jtyr: yes, taken to extreme
15:48:49 <sdoran> To an extent. The idea is that modules need to justify their existence by adding meaningful abstraction. If they are thin wrapper to an API, they add no value.
15:48:53 <bcoca> it is a judgement we have to make, where does overlaping functionality make sense and the ammount of work needed to do same
15:49:20 <sdoran> Modules can and should be a better interface than long shell commands.
15:49:36 <sdoran> Getting a bit off topic, though.
15:49:48 <jtyr> let's move on ...
15:49:52 <sdoran> #topic https://github.com/ansible/ansible/pull/57574
15:50:11 <sdoran> This one is from Akasurde
15:51:07 <sdoran> On behalf of Jakski? I'm not sure what we need to discuss with this one.
15:51:17 <bcoca> hmm, i would use extra conditional, that change  will affect existing behaviour, not just error
15:51:20 <sdoran> Just needs a review?
15:51:43 <tremble> looks like it
15:51:51 <felixfontein> I guess the question is whether the implied change of behavior is something we want
15:52:19 <sdoran> K, I'll review it.
15:52:29 <bcoca> unsure you can create/manage symlinks to files you cannot manipluate, diff issue when it pertains to accessing directory containing it
15:52:44 <sdoran> Probably. Seems like a good bug fix. Not being able to access something is not the same as not existing.
15:53:02 <sdoran> We probably need to handle that a bit differently, though.
15:53:23 <sdoran> #topic https://github.com/ansible/ansible/pull/66071
15:53:29 <sdoran> This is from cyberpear
15:53:45 <tremble> We spent most of the last meeting discussing that one...
15:54:02 <sdoran> So can we move on then?
15:54:12 <sdoran> Is there more to discuss?
15:55:46 <sdoran> Ok, moving on.
15:55:51 <sdoran> #topic https://github.com/ansible/ansible/pull/65747
15:56:03 <sdoran> What say you, felixfontein?
15:56:11 <felixfontein> that's a PR by sivel which I updated
15:56:25 <felixfontein> it does a stronger validation (with schema) for argument_spec
15:57:59 <felixfontein> I think it would be important for sanity check PRs to be merged soon, before modules are moved out to collections, to avoid too many missing ignore.txt entries for these collections
15:58:07 <felixfontein> and this is the next one on the list for me :)
15:58:25 <shertel> if you're just looking for a review I can put it in my queue and try to get to it in the next couple days
15:58:37 <felixfontein> shertel: that would be awesome!
15:58:58 <sdoran> #action shertel to review PR #65747
15:59:05 <felixfontein> I guess sivel is pretty busy with other stuff right now anyway...
15:59:09 <sdoran> Thanks shertel!
15:59:17 <sivel> way too super busy
15:59:18 <felixfontein> thanks a lot, shertel!
15:59:18 <sdoran> felixfontein: bit of an understatement
15:59:22 <shertel> np
15:59:24 <sdoran> We're all busy, some more than others.
15:59:38 <felixfontein> sdoran: I'm not surprised, but I don't see the internal discussions so I have to guess a bit ;)
16:00:23 <felixfontein> there are two more sanity check PRs by tremble, which are related to elements documentation for lists.
16:00:40 <sdoran> We are out of time for today.
16:00:56 <sdoran> I will try to look at them.
16:00:57 <felixfontein> I think they are important as well, the main question I guess is whether blowing up ignore.txt for that is ok (especially for the second PR)
16:01:24 <tremble> And if we're good making 'elements' definitions mandatory when you say type='list'
16:01:29 <felixfontein> that will encourage module authors to improve documentation
16:02:07 <sdoran> That is worthy of discussion.
16:02:24 <sdoran> I would have to look through the code again to form an up to date opinion.
16:02:26 <shertel> Okay, I see them.  I'll acquaint myself and take them into consideration together while reviewing and comment.
16:02:35 * cyberpear late, will try again Tues
16:02:47 <felixfontein> sdoran: shertel: thanks! :)
16:02:52 <sdoran> The elements/subelements code is really... interesting.
16:03:01 <sdoran> Thanks everyone for attending.
16:03:04 <sdoran> #endmeeting