15:59:48 <akasurde> #startmeeting Ansible VMware Working Group Meeting
15:59:48 <zodbot> Meeting started Mon Feb  5 15:59:48 2018 UTC.  The chair is akasurde. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:48 <zodbot> The meeting name has been set to 'ansible_vmware_working_group_meeting'
15:59:58 <akasurde> Hello Everyone
16:01:59 <pdellaert> Hi
16:02:06 <akasurde> #chair pdellaert
16:02:06 <zodbot> Current chairs: akasurde pdellaert
16:02:13 <akasurde> Hi pdellaert
16:02:24 <pdellaert> Sorry i've been absent a little, i'm in the middle of relocating/moving to California/Bay area ;)
16:02:24 * akasurde sighs
16:02:39 <akasurde> np
16:02:44 <dericcrago> hi
16:02:53 <akasurde> #chair dericcrago
16:02:53 <zodbot> Current chairs: akasurde dericcrago pdellaert
16:02:58 <akasurde> hi dericcrago
16:03:15 <akasurde> pdellaert, you didn't miss anything :)
16:03:25 <pdellaert> Well, i did, a lot of PR's ;)
16:04:38 <pdellaert> I have about 10 or 15 e-mails in my inbox on PRs that i need to review ;), which is good, just have to find the time :D
16:04:49 <akasurde> Np
16:05:08 <akasurde> I have been working to get VMware Ansible to a stable state
16:05:27 <pdellaert> yes, we all notice that, which is great!
16:06:18 <akasurde> pdellaert, without your valuable reviews it was impossible
16:06:31 <akasurde> Wanna discuss something
16:06:41 <pdellaert> shoot!
16:07:19 <dericcrago> I wouldn't mind discussing floppy disk status in {vsphere,vmware}_guest ;)
16:07:28 <akasurde> yes sure
16:07:48 <akasurde> pdellaert, what do you thing about Floopy disk support in vmware_guest
16:07:51 <dericcrago> as you know, I created a PR against the now deprecated vsphere_guest
16:07:53 <akasurde> BTW,
16:08:09 <akasurde> #info vsphere_guest is deprecated module from Ansible 2.5 onwards
16:08:38 <dericcrago> to add floppy to the reconfigure functionality in vsphere_guest (it was already there for vm create, just not reconfigure)
16:08:52 <dericcrago> https://github.com/ansible/ansible/pull/35618 for reference
16:09:01 <pdellaert> If floppy support is missing in vmware_guest, we should add it, it's a bit outdated, but some types of VMs might still find a use fore it
16:09:32 <akasurde> #info vsphere_guest floopy support https://github.com/ansible/ansible/pull/35618
16:10:02 <akasurde> I am busy right now, but surely accept PR for this support
16:10:52 <pdellaert> dericcrago: as akasurde mentions, that module is deprecated as it uses a 3rd party unsupported (and unmaintained) library. But a PR on vmware_guest would definitely be accepted :)
16:11:36 <akasurde> dericcrago, You can pdellaert CDROM patch for reference
16:11:50 <dericcrago> yeah, the difference (and why vsphere_guest got the PR) is that vsphere_guest was just missing floppy on reconfigure, vmware_guest has 0 floppy support right now
16:12:34 <pdellaert> yeah, it would be a bit more work...
16:13:45 <akasurde> ok
16:14:20 <pdellaert> I'll spend some time today to do some reviews, so all the work that is being done can be merged in time
16:16:43 <akasurde> Sure thanks
16:16:57 <akasurde> dericcrago, are you interested in raising PR for Floppy ?
16:18:03 <pdellaert> we'll add it to our community action list: https://github.com/ansible/community/wiki/VMware%3A-action-list
16:18:03 <dericcrago> akasurde, sure, it won't be high on my priority list though since for now I'm just using the vsphere_guest PR code for the same funcationality
16:18:40 <akasurde> #action dericcargo Add Floppy support for vmware_guest
16:19:35 <dericcrago> does someone want to officially comment on my PR to reject / close it?
16:20:07 <akasurde> dericcrago, I could. But problem is that there is no integration tests for vsphere_guest
16:20:20 <akasurde> that reminds me,
16:20:42 <pdellaert> akasurde: i don't think we need to accept the PR? If the module is going to be deprecated, should we accept PR's?
16:20:46 <akasurde> pdellaert, dericcrago what do we want to do about vsphere_guest PRs which are opened
16:20:47 <dericcrago> doesn't that mean it passes akasurde ;)
16:21:44 <dericcrago> pdellaert - I don't really disagree, but it's also funtionality that's completely missing
16:21:51 <akasurde> As per my knowledge, if a module is deprecated, then till its removal we need to accept PRs and resolve issues
16:21:55 <dericcrago> I look at as more of a stopgap
16:22:25 <pdellaert> ok, in that case, akasurde, we can review the code and probably just accept it if we are happy
16:23:01 <pdellaert> unless you want to force integration tests on a deprecated module (which might be useful, but will require a lot of work, i think)
16:23:21 <pdellaert> well, not sure, you could partially use the existing vmware_guest tests, just adapt them?
16:24:20 <akasurde> pdellaert, I am OK in merging open PRs if we are OK with syntax and if someone has tested it on their setuo
16:24:37 <akasurde> pdellaert, problem is that vcsim does not support pysphere library
16:25:00 <akasurde> as pysphere library tries to access something internal in vcsim, which vcsim does not like it
16:25:12 <akasurde> I tried it and failed miserably
16:25:30 <akasurde> I left that attempt as I can re-route that efforts for vmware_guest
16:25:31 <pdellaert> ah
16:25:35 <akasurde> makes sense ?
16:26:00 <pdellaert> ok, in that case we accept based on PR quality and user test reports, yes
16:26:28 <akasurde> Cool, +1 for accepting PRs of vsphere_guest based on community reviews and code review comments
16:26:28 <pdellaert> we could ask for an ansible-playbook -vvvv output of the different use cased and an example playbook, just to verify?
16:26:37 <akasurde> sure
16:26:48 <pdellaert> +1
16:27:21 <akasurde> #info Decided to merge vsphere_guest PRs based on community code review and ansible-playbook -vvvv output
16:27:37 <akasurde> What about old and new issues of vsphere_guest
16:29:37 <pdellaert> as this is a deprecated community module, i'd say that if someone wants to fix it, that's fine, but i would keep them low priority... Focus on vmware_* modules
16:29:49 <akasurde> same here
16:30:00 <akasurde> what do you think dericcrago ?
16:30:20 <pdellaert> unless there is missing functionality in vmware_ modules, in which case first priority would be to add it in the vmware_ modules, unless the fix is easy
16:30:50 <pdellaert> (on the vsphere_ modules)
16:31:39 <dericcrago> I agree, like I said, I just did vsphere since it needed less to get the reconfigure floppy functionality
16:32:13 <dericcrago> I'm not thrilled that it's missing from vmware_guest, it was just a much quicker fix to add to vsphere_guest
16:32:16 <akasurde> Ok let us think vsphere_guest as "good to have" kinda of things
16:33:19 <pdellaert> dericcrago: i agree, missing functionality is something different people over the last half year have been looking into and doing a great job on :)
16:33:58 <pdellaert> (even bit longer, actually, time flies)
16:40:17 <akasurde> #action akasurde note down these two decision in vsphere_guest deprecation page
16:41:41 <akasurde> I would like to discuss a possiblity of adding new parameter in vmware_guest called "datastore" outside disk parameter
16:41:57 <akasurde> Idea behind this is that,
16:43:23 <akasurde> I have seen two or more issues where people are deploying from template which resides on different datastore or datastore cluster and they want VM to be deployed on different datastore
16:46:24 <pdellaert> what is the exact use case, for people to deploy the VM on a different datastore (useful, but isn't that supported?), or to place disks on different datastores (also useful, but is going to be more complicated :))
16:46:55 <dericcrago> so top level datastore parameter would be VM configuration location (.vmx file etc) and the disk level datastore would be specifically for the individual disk(s)?
16:47:08 <akasurde> Use case is, People use two datastore, one for template only and other for OS
16:47:29 <akasurde> dericcrago, yes that is another possibility
16:48:11 <akasurde> because, right now current code assumes templates datastore as a default datastore for new VM's datastore
16:48:13 <pdellaert> let's not mix up the two
16:48:15 <akasurde> which is wrong
16:48:28 <pdellaert> first use case is: Template on DS1, VM deployed on DS2, with all its disks
16:49:01 <pdellaert> second (more complicated) use case: Template on DS1, VM (vmx) on DS2, disk 1 on DS2, disk2 on DS3
16:49:11 <pdellaert> (or disk1 on DS4)
16:49:25 <pdellaert> let's start by addressing the first use case, that's a good one to solve
16:49:43 <pdellaert> the other one will follow, but will require the first use case anyway :)
16:49:55 <akasurde> yes correct
16:51:05 <akasurde> If we add datastore parameter then it will take precendence over template datastore and deploy VMX and other file in that datastore
16:51:10 <akasurde> 1st usecase
16:51:32 <pdellaert> sure
16:51:46 <akasurde> and current code will do same as multiple datastore specified in disks in not supported
16:52:26 <akasurde> for second, we need something like this - https://github.com/ansible/ansible/pull/33230
16:54:06 <akasurde> #33230 just considers datastore no datastore cluster though
17:00:18 <pdellaert> (sorry, someone at my desk)
17:00:41 <akasurde> np
17:05:47 <akasurde> We can discuss this in next meeting as we are out of time.
17:06:05 <akasurde> I will close the meeting for today.
17:06:28 <akasurde> or pdellaert would like to discuss this now only ?
17:06:53 <dericcrago> thanks for talking about floppy support today :)
17:07:13 <akasurde> dericcrago, NP
17:22:16 <akasurde> #endmeeting