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