16:00:46 <akasurde> #startmeeting Ansible VMware Working Group Meeting 16:00:46 <zodbot> Meeting started Mon Jul 30 16:00:46 2018 UTC. 16:00:46 <zodbot> This meeting is logged and archived in a public location. 16:00:46 <zodbot> The chair is akasurde. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:46 <zodbot> The meeting name has been set to 'ansible_vmware_working_group_meeting' 16:01:02 <dag> o/ 16:02:23 <akasurde> #chair dag 16:02:23 <zodbot> Current chairs: akasurde dag 16:02:30 <dag> If there's no topic for today's meeting, I don't mind hijacking it :p 16:02:34 <akasurde> Hi dag 16:03:14 <akasurde> dag, we have bunch of pending PRs to do review 16:03:33 <dag> sure, I'll add mine 16:04:54 <akasurde> dag, do you want to discuss something related to docs 16:05:34 <dag> Yes, after I helped a few people with VMware issues I noticed that for total Ansible newbies things are not as clear as I would expected 16:06:20 <dag> one of the problems was related to how to set up your environment, e.g. what needs to be put in the inventory, how does modules work 16:06:33 <akasurde> yes, there is pipeline 16:06:37 <dag> in this case they configured vSphere both in the inventory and for the modules 16:06:56 <dag> so the error was a weird error, but related to SSH to vSphere (which obviously fails) 16:07:05 <akasurde> https://docs.ansible.com/ansible/latest/vmware/index.html 16:07:08 <dag> delegate_to: localhost would have helped 16:07:21 <akasurde> yes, this is in pipeline 16:07:31 <akasurde> I am filling all the blanks here 16:07:34 <dag> but some modules don't have it specified, that's why I created: https://github.com/ansible/ansible/pull/43426 16:07:38 <akasurde> help is welcomed 16:08:38 <dag> What is the "Ansible for VMware Concepts" section for ? 16:09:12 <dag> For Windows and ACI WGs we decided to work on documentation in the Wiki first 16:09:25 <dag> once we are close to what we wanted, it was added via a PR 16:10:01 <dag> to collaborate on content, Github is not helpful (if things only get merged when perfect) 16:12:00 <akasurde> Concepts are something which you are suggesting 16:17:46 <dag> Do you have a concrete example what it is ? 16:19:22 <akasurde> not yet 16:20:42 <dag> I don't understand what it is then, you mentioned I suggested it, but where did I suggest it then ? 16:21:00 <dag> So maybe we can start writing documentation in the Wiki ? 16:22:15 <dag> The wiki supports Restructured Text so it's easy to make a PR out of it later 16:23:55 <akasurde> You said that you want to have guide for newbies like 'delegate_to' 16:24:10 <dag> Not just newbies, everyone 16:24:29 <akasurde> I would prefer docs.ansible 16:24:31 <dag> but starting with the basics (why are VMware modules different than normal modules) 16:24:45 <dag> How do you configure the inventory and provide connection information 16:24:49 <akasurde> people trust more docs.ansible.com 16:24:56 <dag> sure, eventually it ends up on docs.ansible.com 16:25:09 <akasurde> why not do it in docs.ansible 16:25:12 <dag> but to collaborate in Github (where things only get merged when it's done) is cumbersome 16:25:16 <akasurde> in first place 16:25:26 <dag> because the structure in that PR is insufficient 16:25:57 <dag> how can I add content in your PR ? 16:26:10 <dag> I can only add comments, not add content 16:26:34 <akasurde> you can raise PR against my branch 16:26:39 <akasurde> I will merge 16:26:51 <dag> that's why I propose we start writing the documentation in the Wiki and if it's presentable we can turn it into a PR 16:27:03 <dag> sure, that's possible, but IMO not as desirable 16:27:12 <dag> it makes things harder IMO 16:27:33 <dag> but if you prefer to work as you do, that's fine 16:27:49 <akasurde> It is duplicate effort, first write in wiki then docs 16:27:58 <dag> if you think so 16:28:12 <dag> I don't think so, once it's ready to merge, you just make one PR ut of it 16:28:15 <akasurde> we have lot of things on plate 16:28:22 <dag> we did it like that for Windows, and for ACI 16:28:28 <akasurde> "ready" is very relative term 16:28:29 <dag> people can more easily update, improve in a Wiki 16:28:52 <dag> ok, in the time we were discussing I could have written one or two sections already 16:28:57 <akasurde> so do docs.ansible.com PR 16:28:58 <dag> so the discussion is a waste of time now IMO 16:29:02 <dag> sure go ahead 16:30:25 <akasurde> Let us do one thing then 16:30:35 <akasurde> You start adding in wiki page 16:30:51 <akasurde> I will create PR out of it 16:30:54 <akasurde> what say ? 16:31:02 <dag> that's not the point 16:31:08 <dag> the point is to collaborate 16:31:25 <dag> and to work on structure and content 16:31:33 <akasurde> I am not against wiki, but then docs weighs more than wiki IMO 16:31:50 <dag> and at the same time see what you're changing, rendered 16:31:59 <dag> but the wiki is TEMPORARY 16:32:50 <jtanner> are all other cloud modules using delegate_to: localhost in their examples? 16:33:00 <ment0s> is there a way to filter hosts or groups out of the smart inventory ? 16:33:25 <jtanner> smart inventory is a tower concept, please use #ansible-awx or file a support ticket 16:33:48 <dag> jtanner: I don't know, the longterm solution is a VMware connection plugin IMO 16:34:04 <akasurde> yes, it is planned 16:34:22 <dag> but we're not there yet, so I'd prefer we add it to the VMware docs (and leave the examples in a working condition for people that haven't read up on the guide) 16:34:34 <jtanner> a vmware connection plugin was supposed to be something to hit the guest machines over the vcenter api, not a convenience method for vcenter credentials 16:34:49 <dag> jtanner: that's the VMware VM connection plugin (I'd say) 16:35:04 <akasurde> we have vmware_vm_shell 16:35:04 <dag> or maybe we should call it a vcenter connection plugin ;-) 16:35:28 <dag> akasurde: that's to talk to the VM, I'm talking about connecting to vcenter (or ESXi) 16:35:53 <jtanner> not a fan of overloading connection plugins to turn them into convenience methods for folks that don't understand delegation and hostvars 16:36:00 <dag> this is the ACI equivalent: https://github.com/ansible/ansible/issues/36100 16:36:19 <dag> jtanner: the point is that it fits much better in the concept of how Ansible works 16:36:33 <jtanner> people DO want to run cloud modules on remotes sometimes, not just the controller 16:36:45 <dag> you define the targets, and perform tasks to your target 16:36:59 <dag> right, that would be possible with proxy support 16:37:22 <dag> but indeed you'd loose the possibility to run the module elsewhere 16:37:39 <jtanner> it would make sense if connection plugins stacked, but they don't currently. 16:37:49 <dag> I wanted a solution so the connection-information would be coming from the inventory, but without the need for a connection plugin 16:37:58 <dag> but I was told I had to write a connection plugin 16:38:25 <jtanner> the vcenter api is not a "connection" in the ansible sense. who told you that and in what context? 16:38:42 <Alex_5252> According to the documentation - https://docs.ansible.com/ansible/latest/vmware/index.html I watched. All pages are empty 16:38:45 <Alex_5252> :( Such as https://docs.ansible.com/ansible/latest/vmware/vmware_intro.html and https://docs.ansible.com/ansible/latest/vmware/vmware_concepts.html 16:38:58 <jtanner> i mean ... if this is going to be the pattern, do we write a connection plugin for every module that hits some sort of api? 16:39:06 <dag> jtanner: in the context of networking modules 16:39:07 <akasurde> Alex_5252, I am writing those pages 16:39:13 <jtanner> Alex_5252: s/latest/devel 16:39:15 <akasurde> some of them in review 16:39:26 <jtanner> network modules are in a world of their own. 16:39:44 <dag> jtanner: but the problems are the same, and the API's are HTTP-based too 16:40:23 <jtanner> networking flipped the module and connection stack because of paramiko/ssh/python oddities, but it makes little sense if it's hitting a real api 16:40:27 <dag> jtanner: the disucssion was part of: https://github.com/ansible/proposals/issues/81 16:40:55 <dag> no, they have an httpapi and eapi now 16:41:14 <dag> and I know cloud module maintainers are looking at this as well 16:41:25 <jtanner> i don't fully agree with that either 16:41:38 <dag> playbooks would be a lot cleaner, the connection information is stored in ansible.cfg or per target, etc... 16:42:26 <dag> basically everything I stated here: This relates to #33887 16:42:31 <dag> euhm 16:42:43 <dag> https://github.com/ansible/ansible/issues/36100 16:43:14 <dag> this is a direct reference: https://github.com/ansible/proposals/issues/81#issuecomment-338725796 16:43:44 <dag> so I drank their coolaid :) 16:43:45 <jtanner> sigh, i don't have the energy/desire to debate today. you folks can figure it out amongst yourselves 16:43:54 <dag> ok 16:44:55 <dag> bcoca supported the idea of connection plugins, so I considered this was based on consensus 16:46:16 <akasurde> dag, I guess we drifted from documentation topic 16:46:30 <dag> indeed 16:46:55 <akasurde> first finish documentation part then we can move forward to connection plugin 16:47:08 <dag> Well, I opened a few issues and one PR, add you thoughts there 16:47:42 <dag> I actually didn't want to hijack the meeting, that was (a now misplaced) joke ;-) 16:47:59 <dag> reality bit me there 16:48:42 <akasurde> I don't thinks so 16:48:51 <akasurde> we are having healthy discussion 16:52:57 <Alex_5252> I am for a large amount of documentation, although I do not always study it in its entirety. 16:53:11 <Alex_5252> And my contribution is extremely small. 16:56:21 <akasurde> Alex_5252, OK 17:13:41 <akasurde> #endmeeting