15:07:13 <bcoca> #startmeeting ansible core public irc meeting 15:07:13 <zodbot> Meeting started Thu May 16 15:07:13 2019 UTC. 15:07:13 <zodbot> This meeting is logged and archived in a public location. 15:07:13 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:07:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:07:13 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting' 15:08:11 <bcoca> #topic new lvm module 15:08:17 <bcoca> https://github.com/japokorn/ansible/tree/devel-blockdev/lib/ansible/modules/storage/lvm 15:08:20 <bcoca> @japokorn ? 15:08:32 <japokorn> Yup, I am here. So... 15:08:48 <bcoca> https://github.com/japokorn/ansible/blob/devel-blockdev/lib/ansible/plugins/action/lvm.py 15:08:59 <bcoca> what are you looking for from this meeting? 15:09:42 <japokorn> Well, after discussion with sdoran I wanted to make sure that you are ok with putting this into the code. 15:10:20 <bcoca> dont need meeting for that, just ping me in #ansible-devel 15:10:30 <sivel> I'm kind of around, fixing a CI issue currently 15:11:06 <japokorn> The thing is, that the module works in an unusual way. 15:11:30 <bcoca> japokorn: canot really review right now, but adding to my list of things to look at, normally we wait till get a PR to do that 15:11:40 <sdoran> I believe japokorn would like to have these modules merged into Ansible. Since they are doing something a bit atypical — using an action plugin to control the modules — I told him it would be best to discuss with other Core members if that's something we would accept. 15:12:06 <bcoca> we have cases of that happening already .. package/service/yum ... 15:12:12 <bcoca> template/copy/assemble 15:12:14 <shertel> aws 15:12:25 <bcoca> now im terrified ... 15:12:34 <shertel> looks reasonable to me. The result["changed"] += stuff is doing odd stuff. 15:12:35 <sdoran> Doesn't mean we want more of it. :) 15:12:39 <shertel> (aws_s3 action module) 15:12:47 <shertel> plugin 15:13:09 <sdoran> Is the general idea of an action plugin controlling _multiple_ modules ok? 15:13:10 <shertel> I need coffee, I can't english 15:13:17 <sdoran> I think that's the main thing I wanted other opinions on. 15:13:23 <bcoca> sdoran: see gather_facts in 2.8 15:13:24 <sdoran> To save japokorn from wasting time. 15:13:42 <bcoca> im not against it on principle, but modules should also be 'independantly usable' 15:13:49 <japokorn> They are. 15:14:18 <japokorn> The whole point is to avoid redundancy in code. 15:14:36 <japokorn> And also not to create monstrous chunk of code noone understands. 15:14:56 <bcoca> that NEVAR happens!!! .... 15:15:03 * bcoca stares at fact gathering 15:15:45 * japokorn looking at his fingernails 15:15:53 <bcoca> japokorn, sdoran i'll give a look later, dont think we want to reject this on principle of 'lots of logic on action plugin' since that is what action plugins are for 15:16:00 <shertel> why not use module_utils? 15:16:30 <bcoca> ^ valid question, mostly you want ot use action plugins when you NEED to do actions controller side 15:19:31 <japokorn> That depends. Is it possible to call multiple modules using it? 15:20:02 <shertel> you'd import the module_utils from your module 15:20:19 <shertel> you can still share classes among your modules 15:20:58 <dlehman> the purpose of the action plugin is, I think, to provide a higher-level entry-point (one module call to set up full lvm stack rather than one call per layer) 15:20:59 <japokorn> I have to admit, that I would like avoid running this thing on controller side. 15:21:08 <dlehman> correct me if I'm wrong there, japokorn 15:21:10 <sivel> so effectively this action plugin does what you would otherwise do in 3 tasks in a playbook 15:21:20 <bcoca> the question deals with 'shared code' vs multiple module call (which only actions can do) or you can design modules to have most of code shared in module_utils 'effectivley' composing the module depending on what you need 15:21:45 <sivel> so it's just calling lvm_pv->lvm_vg->lvm_lv instead of calling those separately in a playbook 15:21:46 <shertel> Yeah, that was just my query in regard to "The whole point is to avoid redundancy in code." 15:22:09 <sdoran> @sivel Yes. Is that something we'd accept upstream? That's the main point of this topic. 15:22:15 <bcoca> ^ which is exactly why you should use module_utils, action plugin is not as much for shared code as for 'controller logic' 15:22:15 <sivel> I'm not sure we should 15:22:29 <bcoca> depends, i have not looked at plugin 15:22:38 <bcoca> dont konw what it is doing or what it requries 15:22:48 <bcoca> i think discussion will be too theoretical till we examine code 15:22:53 <sivel> I don't think we should be accepting action plugins, that just take the place of 3 tasks in a playbook, by instead just executing 3 modules via an action plugin 15:22:55 <sdoran> japokorn: Can you elaborate on why it needs to be done this way? 15:23:19 <sivel> I'm looking at the code right now 15:23:25 <sivel> which is how I've come to this conclusion 15:23:25 <bcoca> sivel: agreed on that simple premisse, but we do things like tempalte/copy that use several modules for single purpose 15:23:31 <bcoca> so 'it depends' 15:23:42 <bcoca> sivel: ok, i have not, but i trust your conclusion 15:24:22 <sivel> See this example: https://github.com/japokorn/ansible/blob/devel-blockdev/lib/ansible/modules/storage/lvm/lvm.py#L90-L105 15:24:37 <sivel> it's basically a way to shove all module args into a single module 15:24:40 <sivel> and then execute 3 modules 15:24:57 <japokorn> I don't think that it needs to be run this way. The main reason is having it this way is splitting it into some structure that can be used independently. 15:25:51 <bcoca> yeah, i would create 'meta module' that has those args and then calls common code ni module_utils, you dont need an action plugin for that 15:26:00 <japokorn> Yes, the action plugin only decides in which order (and with which params) are the modules called. 15:27:26 <sdoran> Sounds like 👎 to the action plugin but modules themselves may be ok, pending review. 15:27:34 <japokorn> I suppose module_utils can do that better. I have never used them though. :/ 15:27:39 <sdoran> And using module_utils would be preferable. 15:28:11 <sivel> japokorn: in short module_utils are just shared code that many modules can import and use 15:28:25 <bcoca> agreed with sdoran and sivel 15:28:35 <shertel> also agreed 15:29:32 <bcoca> k, seems that is settled (and i have one less item on review list) 15:29:38 <bcoca> #topic open floor 15:30:29 * japokorn starts rewriting code to use module_utils 15:41:09 <bcoca> k, nothing new, so this is it for today 15:41:12 <bcoca> #endmeeting