16:00:25 <akasurde> #startmeeting Ansible VMware Working Group meeting
16:00:25 <zodbot> Meeting started Mon Oct  7 16:00:25 2019 UTC.
16:00:25 <zodbot> This meeting is logged and archived in a public location.
16:00:25 <zodbot> The chair is akasurde. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:25 <zodbot> The meeting name has been set to 'ansible_vmware_working_group_meeting'
16:00:38 <akasurde> #chair n3pjk Goneri
16:00:38 <zodbot> Current chairs: Goneri akasurde n3pjk
16:01:30 <akasurde> n3pjk, hi
16:01:49 <n3pjk> Hello!
16:02:50 <akasurde> Would you like to discuss https://github.com/ansible/community/issues/423#issuecomment-537189058
16:03:21 <Goneri> #topic https://github.com/ansible/ansible/pull/28552
16:03:50 <nre-ableton> yes, that's my PR
16:04:20 <akasurde> #chair nre-ableton
16:04:20 <zodbot> Current chairs: Goneri akasurde n3pjk nre-ableton
16:04:25 <nre-ableton> I'd basically like to figure out if this is a desirable change, and if so, what work needs to be done to get it merged
16:04:32 <nre-ableton> otherwise I'll abandon it
16:04:53 <akasurde> nre-ableton, Sorry that we didn't merge it yet
16:05:12 <akasurde> I am thinking about use cases
16:05:21 <nre-ableton> well, no problem :) my understanding is that there is some hesitancy to merge, based on the fact that some users might rely on the old behavior
16:05:25 <Goneri> hi nre-ableton! I think it's a sensible change.
16:05:26 <akasurde> Can you elaborate
16:05:34 <nre-ableton> to that end, I have no idea if this is true or not. I am biased by my own use-cases.
16:06:15 <nre-ableton> @akasurde https://github.com/ansible/ansible/pull/28552#issuecomment-406625222
16:06:36 <Goneri> however it makes the previous behavior, so he should to introduce it in a major version and it should not be backported.
16:07:31 <nre-ableton> Goneri: so should I attempt to get it merged to 2.9?
16:07:42 <akasurde> 2.10
16:07:47 <nre-ableton> gotcha
16:07:59 <akasurde> I am ok merging this for 2.10
16:08:00 <Goneri> yes, 2.9 already lives in its own branch.
16:09:25 <nre-ableton> I'm not exactly clear on the procedure for getting this fix in 2.10, but not backporting it to other branches. However, we can discuss this exact process in DM so as not to sidetrack the meeting.
16:12:20 <akasurde> nre-ableton, I merged this for 2.10
16:12:25 <Goneri> nre-ableton, merged, thanks for the contribution and your patience :-)
16:12:27 <Goneri> <3
16:12:28 <nre-ableton> akasurde: cool, thanks!
16:12:43 <nre-ableton> Goneri: no problem, thank you both for your help in getting this merged. I'm glad to finally see it land.
16:13:15 <Goneri> #topic should we advice the user to base the new modules on vmware_httpapi?
16:13:57 <akasurde> nre-ableton, Keep eye on bugs which might sprang up
16:14:16 <nre-ableton> akasurde: good point, will do. I'll file a GitHub issue should I see any.
16:14:23 <Goneri> So this one is more an open discussion, n3pjk has done a new family of VMware modules based on the REST API
16:14:38 <akasurde> nre-ableton, Sometimes PR needs some love and some attention
16:14:39 <akasurde> hehehe
16:15:27 <akasurde> n3pjk, I am OK guiding people to new HTTPAPI interface and motivating them to develop new module based upon this
16:15:31 <n3pjk> Here is the link to the design for the new family of VMware modules based on VMware's REST vSphere SDK spec.  https://github.com/ansible/community/wiki/VMware:-HTTPAPI-connection-plugin
16:15:44 <akasurde> But I see there are some functionalities missing in REST API
16:16:10 <n3pjk> Yes. VMware has not provided a complete spec.  At least, not yet.
16:16:43 <Goneri> the associated PR: https://github.com/ansible/ansible/pull/60914
16:17:05 <akasurde> n3pjk, Yes, Ansible Team had talk with Vmware team in AnsibleFest
16:17:07 <n3pjk> Where the spec is deficient, for example, managing licensing, or NSX, we'll have to rely on the pyvmomi, SOAP, implementations
16:17:17 <Goneri> I suggest we update the VMware contribution guidelines, to explain the purpose of these modules
16:17:25 <akasurde> VMware promised to release missing pieces as soon as possible
16:18:27 <akasurde> n3pjk, Do you think adding documentation helps ?
16:18:51 <n3pjk> Documentation always helps. Can't have too much of it!
16:19:57 <n3pjk> I can add more information to the design spec to flesh it out.
16:20:48 <Goneri> #action Goneri update the VMware contribution guidelines to introduce the new modules
16:21:06 <n3pjk> I also need to document the VmwareRestModule extension of AnsibleModule, anyway.
16:21:10 <Goneri> #action n3pkj add more information to the design spec to flesh it out
16:22:26 <akasurde> Or Writing a module development in https://docs.ansible.com/ansible/latest/scenario_guides/guide_vmware.html
16:22:37 <Goneri> +1
16:22:41 <akasurde> n3pjk, thanks
16:23:00 <akasurde> Just start a doc and we can collaborate
16:23:11 <n3pjk> Will do.
16:23:43 <akasurde> n3pjk, thanks
16:23:59 <Goneri> Are we done with this topic? Can I jump to the next one?
16:24:18 <n3pjk> Does anyone have any questions about these modules?
16:24:28 <akasurde> Nope
16:24:37 <akasurde> Goneri, yes please
16:24:52 <Goneri> #topic should we migrate the existing modules that use ansible.module_utils.vmware_rest_client to the new vmware_httpapi fundation?
16:25:21 <Goneri> To summarize, the now have to family of VMware modules that are both based on the REST API
16:25:48 <akasurde> I think for migration we should wait for REST interface completion
16:25:49 <Goneri> the ones based on vmware_rest_client.VmwareRestClient and the new ones
16:25:55 <akasurde> From VMWare side
16:26:48 <Goneri> I'm afraid we will end-up with some kind of conflict in the vmware_ namespace
16:27:14 <Goneri> say I start a REST API vmware_datacenter module, how should I call it?
16:27:27 <n3pjk> I have tried to make sure there is no conflict with the module names for the new family.
16:27:35 <Goneri> and what is we also have a datacenter module, but based on VmwareRestClient
16:27:59 <n3pjk> The format is vmware_<REST API>_<object>
16:28:15 <n3pjk> So that example would be vmware_vcenter_datacenter.
16:29:08 <Goneri> I see, that's something that we need to cover in the guidelines.
16:30:16 <akasurde> Goneri, I agree
16:30:43 <Goneri> #action Refresh the vmware contribution guidelines to explain the purpose of the HTTPAPI modules and the naming convention
16:30:48 <n3pjk> A number of modules center around metadata, so those are covered in the vmware_cis_* section of the design.
16:31:27 <n3pjk> I'll need to make that explicit in the design as well.
16:32:54 <Goneri> Do we have anything else to cover?
16:33:05 <n3pjk> The one unfortunate thing, is that the new family will require, at the very least, some changes to playbooks to use them. At the very least, the connection needs to be changed to 'httpapi'.
16:34:05 <n3pjk> I have grouped related API calls into modules, so the functionality may not be a 1:1 mapping with the current modules either.
16:34:44 <Goneri> agreed, this is what makes a "transition" a bit tricky
16:35:54 <n3pjk> So connection, the non-colliding naming convention, and related API calls, will make things potentially a shift.
16:38:08 <Goneri> Thanks n3pjk for the clarification
16:39:00 <Goneri> I believe we can now close the meeting,
16:39:07 <Goneri> #endmeeting