16:03:32 <akasurde> #startmeeting Ansible VMware Working Group Meeting
16:03:32 <zodbot> Meeting started Mon May  7 16:03:32 2018 UTC.
16:03:32 <zodbot> This meeting is logged and archived in a public location.
16:03:32 <zodbot> The chair is akasurde. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:32 <zodbot> The meeting name has been set to 'ansible_vmware_working_group_meeting'
16:03:45 <akasurde> Hello Everyone
16:07:20 <pdellaert> hi
16:07:30 <pdellaert> so, this meeting is set wrong in my agenda :p
16:07:36 <pdellaert> i thought it was an hour ago ;)
16:08:52 <akasurde> #chair pdellaert
16:08:52 <zodbot> Current chairs: akasurde pdellaert
16:09:03 <akasurde> pdellaert, how are you ? long time no seen
16:10:28 <pdellaert> yeah, it's insane at the moment :)
16:10:34 <pdellaert> i'm good, just very busy
16:10:49 <pdellaert> but decided it was time to do some reviews yesterday :)
16:11:02 <pdellaert> How are you?
16:11:23 <akasurde> Yeah. I missed your reviews.
16:11:25 <akasurde> I am good
16:11:49 <akasurde> will wait for some more people
16:13:24 <pdellaert> reviews is the first step, i hope to develop some new stuff in the future as well, just... when :p
16:14:15 <akasurde> Reviews is very important. I get totally different prespective from reviews
16:18:19 <akasurde> #link https://github.com/ansible/ansible/pull/36026
16:18:21 <pdellaert> dag: are you going to RH summit this week, btw?
16:18:32 <akasurde> want to discuss this ?
16:18:45 <dag> pdellaert: no
16:19:08 <dag> never been to RH summit
16:19:24 <akasurde> #chair dag
16:19:24 <zodbot> Current chairs: akasurde dag pdellaert
16:19:49 <pdellaert> ok :)
16:20:03 <pdellaert> akasurde: sure, what do you want to discuss?
16:20:18 <akasurde> Vmware_guest_disk_facts returns disk details as
16:20:18 <akasurde> https://github.com/ansible/ansible/pull/36026/files#diff-0b68b1d324aa3ebc48f8dd3f292f5e47R91
16:20:55 <pdellaert> ok, but it's merged, i see?
16:21:48 <dericcrago> hi
16:21:57 <akasurde> yes, but there is concern that datastructure is complicated
16:22:03 <akasurde> #chair dericcrago
16:22:03 <zodbot> Current chairs: akasurde dag dericcrago pdellaert
16:22:36 <akasurde> I implmented it as dict of disk details
16:22:53 <pdellaert> ah, yeah, that comment makes sense
16:22:54 <akasurde> What are your opinion on this
16:23:16 <pdellaert> unless there is a very good reason for having a dict (there is some key value you want to show) we should probably do a list, indeed
16:23:46 <pdellaert> the only reason to use a dict, is if you make the key the label
16:24:20 <akasurde> I forgot why I added dict instead of list
16:24:36 <pdellaert> which might be useful if they want to access the info for certain disk
16:25:10 <pdellaert> the use of facts modules is to give easy access to data about an object. So a list of disks is nice, but harder to parse in Ansible. Using a dict, with a proper key, could be useful
16:26:05 <pdellaert> as far as i know, the label is persistent
16:26:11 <pdellaert> do we have a module for nic facts?
16:26:27 <akasurde> but imagine this disk facts as input when you are reconfiguring VM
16:26:27 <akasurde> I am planning
16:27:50 <pdellaert> yeah, so what is the easiest way to use these facts as input when you are reconfiguring a VM
16:28:59 <pdellaert> a list makes it hard to find the right disk (you have to loop through the list, match on a criteria, set a new fact, and then execute the task on that new fact)
16:29:43 <pdellaert> while if you have a dict with a proper key, you can still do that if the key is not the right criteria(i think), but if it is the right criteria for you, it makes it a lot easier
16:30:03 <pdellaert> so what key would make sense? (i'd say label, but that's just my view)
16:32:36 <akasurde> sorry, did I miss anything ?
16:33:39 <pdellaert> yeah, so what is the easiest way to use these facts as input when you are reconfiguring a VM
16:33:42 <pdellaert> a list makes it hard to find the right disk (you have to loop through the list, match on a criteria, set a new fact, and then execute the task on that new fact)
16:33:47 <pdellaert> while if you have a dict with a proper key, you can still do that if the key is not the right criteria(i think), but if it is the right criteria for you, it makes it a lot easier
16:33:51 <pdellaert> so what key would make sense? (i'd say label, but that's just my view)
16:34:11 <pdellaert> (just repeated the last messages after your last reply)
16:34:25 <akasurde> I would prefer dict as label identifies order and I am sure about order
16:36:01 <pdellaert> agreed
16:36:16 <pdellaert> so seems we are on the same page :)
16:36:26 <pdellaert> let me put it as a comment on the PR for phemmer
16:36:44 <akasurde> I agree that dict parsing is difficult in Ansible
16:37:23 <akasurde> it is added in 2.6 so we can make changes
16:37:33 <pdellaert> is it much more difficult then parsing a list of dicts?
16:38:36 <pdellaert> so, just to be safe: we still want to use a dict, but actually have a proper key, suggestion is 'disk.deviceInfo.label' currently
16:38:51 <akasurde> yep. agreed
16:40:44 <akasurde> Ok. We can move to new topic
16:40:49 <akasurde> #topic documentation page
16:41:08 <akasurde> We have a new documentation page - http://docs.ansible.com/ansible/devel/vmware/index.html
16:41:35 <akasurde> Hurray
16:42:11 <pdellaert> nice :)
16:42:20 <pdellaert> confrats :)
16:42:49 <pdellaert> congrats
16:43:07 <akasurde> This is a new effort to clear things around usecases and possible sceanrios with known issues and caveats
16:43:13 <akasurde> Thanks pdellaert
16:43:43 <pdellaert> i'm assuming you'll be working on that mainly?
16:44:35 <akasurde> Yeah. Mostly, me and jctanner, PRs are welcome
16:45:30 <akasurde> #link http://ansibullbot.eng.ansible.com/ansibot/metadata/byfile_sorted.html
16:46:38 <akasurde> vmware_guest is still at top spot, target is to bring it stable version and out of top 10
16:46:44 <pdellaert> that's a long list ;)
16:47:18 <akasurde> Yup
16:49:08 <pdellaert> The problem is that we are adding so much functionality in managing a guest, that it is very hard to cover all potential code paths
16:50:07 <pdellaert> wondering if it makes sense to start splitting functionality off (but it will be hard to determine how), some obvious things could be to split off the cloning from a template into a separate module
16:50:19 <pdellaert> with close to no modification functionality
16:50:32 <pdellaert> and then have other modules who can actually do the modifications
16:50:39 <akasurde> Yes.
16:50:58 <dericcrago> akasurde has been doing his best to make a module for everything ;)
16:51:03 <pdellaert> yeah, indeed
16:51:17 <akasurde> dericcrago, pdellaert thanks for appericating my efforts
16:51:58 <akasurde> I feel current module is OK at moment, we just need to make it stable for all
16:52:17 <pdellaert> but if we make a concious choice of this effort of splitting off, we need: 1) a design/plan of how/what we split; 2) stop adding new functionality in vmware_guest and start immediately with new modules, so we can eventually deprecate vmware_guest for the split off modules
16:52:22 <akasurde> pdellaert, suggested good idea of implementing sub_argument_spec
16:53:00 <pdellaert> but if that's in place (i've missed the last few months of meetings), then i'm all good :)
16:53:07 <akasurde> which might clean user data
16:53:23 <dericcrago> I've started to see the light and agree with what you're saying in 2 pdellaert
16:54:06 <akasurde> Agree. We stop adding new features vmware_guest
16:54:14 <pdellaert> and yes, with the new module signature capabilities, using sub arguments and other features (require_one_of, require_together, ...) would be a worthy clean up effort
16:54:47 <akasurde> pdellaert, I totally agree.
16:54:50 <dericcrago> I haven't kept up with the status of the sub arg stuff, is that ready for primetime now?
16:55:04 <pdellaert> have we kept the VMware community wiki up to date? (sorry again, been out way to long)
16:55:23 <pdellaert> dericcrago: seems to be, it's been there since 2.4 and has been implemented in many modules
16:55:23 <akasurde> from my point of view, I updated it
16:55:32 <pdellaert> akasurde: great :)
16:55:52 <dericcrago> pdellaert - cool, thanks
16:57:28 <akasurde> dericcrago, you can see example of pdellaert - vmware_dvs_portgroup
16:58:57 <pdellaert> this one captures most capabilities as well: https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/network/nuage/nuage_vspk.py#L992-L1006 (easy to promote my own work, but it helps a lot as an example)
16:59:18 <akasurde> pdellaert, thanks for link
17:00:33 <pdellaert> not sure if the required_one_of and stuff works for sub specs
17:00:45 <pdellaert> if not, time for a new feature request ;)
17:00:52 <pdellaert> anyway, i have to drop, sorry
17:00:54 <pdellaert> thanks all!
17:01:17 <pdellaert> i'll see if i can update the wiki with some stuff i have
17:01:33 <dericcrago> thanks for all your review work over the weekend pdellaert
17:02:40 <akasurde> pdellaert, I guess it works
17:02:47 <akasurde> no_log and other stuff
17:03:23 <akasurde> pdellaert, yes, your reviews helps me a lot
17:06:26 <pdellaert> akasurde: i meant specifically the 'required_on_of', 'required_if', 'mutually_exclusive' and such
17:06:56 <pdellaert> the one that identify that certain main spec items have special behaviour/requirements. Not sure if you can specify that on sub spec
17:07:58 <akasurde> I need to check first, I am 80% sure
17:08:10 <akasurde> Let me do some POC and get back to you
17:15:42 <akasurde> I don't have anything else to discuss
17:15:53 <akasurde> Does anyone have anything else to discuss ?
17:21:44 <akasurde> I will close the meeting for now.
17:21:47 <akasurde> #endmeeting