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