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