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