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