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