16:00:47 <akasurde> #startmeeting Ansible VMware Working Group Meeting 16:00:47 <zodbot> Meeting started Mon Aug 7 16:00:47 2017 UTC. The chair is akasurde. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:47 <zodbot> The meeting name has been set to 'ansible_vmware_working_group_meeting' 16:00:59 <dag> o/ 16:01:13 <akasurde> #chair dag 16:01:13 <zodbot> Current chairs: akasurde dag 16:01:18 <akasurde> dag, hi 16:01:35 * dag notices we are using "ansible_vmware_working_group_meeting" for this WG, so I will have to change the link in the WG README.md 16:01:57 <akasurde> ok 16:02:22 <jtanner> hello 16:02:25 <dahr> Where are we meeting today? 16:02:26 <akasurde> #chair jtanner 16:02:26 <zodbot> Current chairs: akasurde dag jtanner 16:02:31 <akasurde> #chair dahr 16:02:31 <zodbot> Current chairs: akasurde dag dahr jtanner 16:02:42 <akasurde> dahr, here :) 16:03:29 <pdellaert> o/ 16:03:36 <jtanner> don't have to talk about this now, but the simulator has been unstable for some tests https://app.shippable.com/github/ansible/ansible/runs/30778/39/tests 16:03:37 <akasurde> #chair pdellaert 16:03:37 <zodbot> Current chairs: akasurde dag dahr jtanner pdellaert 16:04:00 <dericcrago> hi 16:04:04 <dag> jtanner: good to know 16:04:14 <akasurde> #chair dericcrago 16:04:14 <zodbot> Current chairs: akasurde dag dahr dericcrago jtanner pdellaert 16:04:28 <dag> jtanner: sometimes it would be nice to have a CI status overview, so that when CI is going haywire, we don't have to guess :-) 16:04:39 <jtanner> *shrug* 16:04:53 <jtanner> ci_verified was the first step towards that iirc 16:05:07 <jtanner> we've started to at least have some data about who's at fault 16:05:12 <dag> right 16:05:43 <jtanner> mattclay is the head honcho for that sort of thing though 16:05:49 <akasurde> what do we have on today's agenda 16:05:55 <akasurde> #chair jdatx 16:05:55 <zodbot> Current chairs: akasurde dag dahr dericcrago jdatx jtanner pdellaert 16:06:42 <dag> jtanner: I'll put it on the agenda of the Test WG 16:06:50 <jtanner> cool 16:07:00 <dahr> I'm currently in transit to Toronto but myself and Jake are here to answer any questions and provide input. 16:07:20 <akasurde> #action dag To put VMware + ci_verified related to stuff to Test WG 16:07:45 <akasurde> dahr, sure thanks 16:07:52 <jtanner> were there other topics? 16:08:06 <akasurde> I don't see any 16:08:10 <jtanner> k 16:08:18 <jtanner> well, i have some thoughts about the simulator issues 16:08:32 <akasurde> #topic govcsim simulator issues 16:08:40 <akasurde> jtanner, go ahead 16:08:54 <jtanner> i suspect there might be some conflicts with spinning up the contain for multiple concurrent tests 16:09:18 <jtanner> we need to confirm if each test run gets it's own instance of the container or if it's shared among all 16:09:48 <jtanner> second, we need to have the spawn route do better validation on startup and return an error code if not sucess 16:10:11 <jtanner> and tests to fail earlier instead of using the error message as a value for module inputs 16:10:40 <akasurde> ok 16:10:50 <jtanner> stuff i should have done on initial implementation but got overwhelmed with $WORK 16:11:11 <dag> akasurde: there were various PR's raised in the agenda, maybe refresh the agenda issue ? 16:11:17 <pdellaert> (sorry on two calls at once, i'll read , but ping me if important) 16:12:09 <akasurde> dag, ok 16:13:06 <akasurde> jtanner, what do you suggest for simulator issue then ? 16:13:26 <jtanner> exactly what i said above i guess 16:13:39 <dahr> Aside from our initial call, how would you like us (vmware) to assist in your iniatives? 16:14:32 <dag> akasurde: I see a lot of entries in the agenda that are not fully struck (strikken, stroke?), which means they are not completed. Apart from the new-modules review (which we always should review to see if there's anything that is stuck 16:14:42 <jtanner> dahr: if you guys are really offering time, it would help to start with review on PRs and/or triage on open issues 16:15:10 <akasurde> #action jtanner Look into running separate container for govcsim 16:15:16 <dag> dahr: There are a lot of GPL3+ modules that look quite interesting in your Github repository 16:15:30 <dag> dahr: I wonder if there is a plan to get those upstream ? 16:15:33 <akasurde> dag, yes there are pending due to code-review 16:15:53 <akasurde> they == PR* 16:16:06 <bcoca> wouldnt that be 'downstream'? 16:16:15 <akasurde> #chair bcoca 16:16:15 <zodbot> Current chairs: akasurde bcoca dag dahr dericcrago jdatx jtanner pdellaert 16:16:41 <dag> bcoca: depends, for people using Ansible I'd say Ansible is upstream and VMware github is 3rd party 16:16:41 <jdatx> yes, I'm currently looking at removing any overlap on whats currently in our GPL3 and other module repos 16:17:51 <akasurde> dahr, There is also a need of "magic" method to find objects 16:18:07 <dahr> Understood. I'm not sure how much time we can commit to but once we scope the needs, we can start putting some time in. This is helpful. Do we have a contact point? 16:18:36 <jtanner> contact in what context? 16:18:47 <bcoca> ^ thaumos? 16:18:58 <jtanner> i'm almost always available via email, but #ansible-vmware is the goto spot 16:19:13 <jtanner> jtanner@redhat.com 16:19:21 <bcoca> normally one or more core team here or in other irc channels 16:19:39 <dag> ok, so who would "scope the needs" and make a proposal plan 16:20:03 <jtanner> seems like something that the whole group should devise 16:20:29 <jtanner> devise/design/deliberate 16:20:32 <dag> jtanner: what would the modus operandi then be ? During special meetings, one-by-one reviewins ? 16:20:54 <dahr> Lol, every time I start to type, you guys already get the conversation going. 16:21:08 <akasurde> first priority will be making existing modules robust and finish with existing issues 16:21:08 <dag> dahr: welcome to IRC ;-) 16:21:26 <bcoca> then 'feature completeness' 16:21:46 <akasurde> I think we have pretty much load of things on plate right now 16:21:47 <jtanner> dag: i dunno ... i hate meetings. i prefer tickets and working through them adhoc 16:21:56 <dahr> Agreed. 16:21:58 <akasurde> yes, feature completeness is also priority 16:22:10 <jdatx> + 1 @jtanner ^^ 16:22:19 <jtanner> vsphere_guest -> vmware_guest priority 16:22:25 <dag> akasurde: sure, but I picked up that if there is a plan, we'd have extra resources 16:22:48 <dag> akasurde: if you propose we first do the stuff we are doing, this is being blocked to a point that is undefined and may never happen 16:22:51 <akasurde> #link https://github.com/ansible/community/wiki/VMware%3A-vsphere_guest_deprecation 16:23:02 * dag prefers unblocking people in this case 16:23:20 <dag> maybe it means "only do the stuff that does not overlap" 16:23:32 <jtanner> https://github.com/ansible/community/wiki/VMware%3A-action-list looks like a "plan" to me 16:23:34 <dahr> The issue on our side is that we have so much going on (i.e. repo tracking on our end, engagements, etc...) that I want to be sure we have visibility to your needs. 16:24:08 <dag> jtanner: well, that plan is updated all the time, so we could add individual tasks for the VMware people 16:24:15 <akasurde> we also lack reviewers which make PR submission and merge process slow 16:24:16 <dag> jtanner: my question is, what would those tasks be 16:24:34 <jtanner> dunno, everything depends on time commitment 16:24:47 <jtanner> review requests may be a good initial phase 16:24:55 <dag> jtanner: and time commitment is hard if there's no scope and no requirements 16:25:06 <akasurde> dag, same here 16:25:22 <dag> yeah, so that's not how the community works (even we all want it to work like this) 16:25:42 <dag> "you can only work on the stuff *you* would like to do, if you first emerge yourself in the stuff *we* want to get done" 16:25:51 <jtanner> heh 16:25:52 <dahr> For context, we are not solely dedicated to development as we are also PSO. Therefore, we'll need to plan some time around collab with you guys. 16:26:28 <bcoca> bugfixes / review can be done with limited commitment X hours a week 16:26:41 <jtanner> dahr: most people are in the same boat 16:26:44 <bcoca> having a development plan for rest can still be done in p;arallel 16:27:21 <dag> so my proposal is that we first set the scope (e.g. make a list of modules that do not overlap with existing modules), get those submitted and reviewed 16:27:33 <dahr> Perfect. I just want to set expectations to limit disappointment. 16:27:39 <jtanner> dahr: maybe we could start with getting your github nicks added to the wiki, so akasurde/dag/etc could request your reviews on PRs? 16:27:46 <dag> (if the reviews go too slow, you can help out reviewing other stuff so others can help with your stuff) 16:27:58 <dahr> Jake, are you catching this? 16:28:03 <jdatx> yes sir 16:28:55 <akasurde> #action akasurde add nick wise PR for review request 16:29:19 <dag> in the process of submitting these PRs and the reviews, I am sure new decisions and library updates will happen, and people will get to know processes and people 16:29:25 <jdatx> @jtanner - my todo is to remove anything in the vmware module repos that ansible currently supports and look to get non overlapping modules into upsteam 16:29:42 <dahr> Perfect. I'll make some notes, circle up with Jake and Tom Scanlan and them put a plan together. 16:29:52 <dag> we can track the progress of this "project" from: https://github.com/ansible/community/wiki/VMware%3A-progress-tracker 16:30:10 <jtanner> oh ... i just remembered something 16:30:16 <jtanner> and it would help if vmware contributed 16:30:17 <akasurde> #action jdatx to remove anything in the vmware module repos that ansible currently supports and look to get non overlapping modules into upsteam 16:30:19 <dag> just add a new section, list the modules one-by-one, add the PR numbers in there 16:30:40 <jtanner> we need an FAQ on why we don't have tagging support in vmware_inventory.py or vmware_*.py 16:30:59 <jtanner> something to explain how the soap api doesn't deliever tags 16:31:02 <jtanner> deliver* 16:31:39 <jtanner> i get pinged on that at least once a month 16:32:34 <akasurde> jtanner, Do you think a wiki page will help ? 16:32:42 <dahr> I think it would. 16:32:48 <jtanner> yes, should be okay 16:33:06 <jtanner> official docs doesn't do "FAQs" imo 16:33:21 <akasurde> Ok I will start a page in wiki, dahr/jdatx can work on it 16:33:27 <jtanner> cool 16:33:52 <akasurde> #action akasurde add a wiki page for FAQs to discuss issues like tagging support 16:33:53 <jtanner> i can also add some stuff about how to perf tune vmware_inventory.py 16:34:00 <jtanner> which is another thing i get pinged about 16:34:27 <akasurde> Perf == magic method to find objects :) 16:34:35 <jtanner> heh, no 16:34:38 <dahr> Guys, I'm sorry but I gotta run. Need to eat lunch before my flight. If you can, please send a summary email to dahr@vmware.com and jdupuy@vmware.com 16:35:11 <akasurde> dahr, Ok, sure. 16:35:33 <dahr> If you guys feel the need for it, I can set up a recurring webex (monthly, bi-weekly) to discuss. 16:35:39 <jtanner> perf == limiting the properties collected instead of serializing everything 16:36:03 <dahr> I hate meetings but I see a need for them....from time to time. 16:36:09 <jtanner> dahr: let's continue on with this meeting for a bit long (we're still new at it) 16:36:18 <jtanner> a bit longer* 16:36:21 <dag> dahr: I think we all prefer these weekly IRC meetings to track progress, or unblock things 16:36:37 <dahr> No worries. Just let me know. You guys take care and we'll start working towards a tighter collabe. 16:36:40 <dahr> *collab 16:37:07 <dag> but you can always ask here for advice 16:37:52 <dag> ok, that was useful ! (closes one of the questions on the wiki I had wrt. the VMware modules, I'll write up a brief summary) 16:38:01 <dag> can we go to the normal agenda now ? :-) 16:38:15 <akasurde> if wee don't have anything else we can start with dag's requests 16:39:41 <akasurde> #link https://github.com/ansible/ansible/pull/25140 16:40:01 <akasurde> need a second shipit on this ^^ 16:40:04 <dag> dahr, jdatx, Tom Scalan, if you want to raise a topic to this meeting, you can do that here: https://github.com/ansible/community/issues/206 16:40:23 <dag> Also please add your name/github id at: https://github.com/ansible/community/blob/master/group-vmware/README.md 16:41:05 <dag> akasurde: so I would like to get that merged 16:41:59 <dag> akasurde: I already regretted making that PR, but not pushing through would make it all an ever bigger waste of time 16:42:12 <jtanner> it's going to remain needs_revision until that version_added error is fixed 16:42:24 <dag> jtanner: that version_added is not an error 16:42:33 <dag> jtanner: the parameter was undocumented 16:42:47 <akasurde> state was undocumented 16:42:54 <dag> (and it's always a hassle to get those things fixed because everyone believes the CI more than me :-)) 16:43:06 <jtanner> we still have to make the test pass 16:43:07 <akasurde> hehe 16:43:15 <jtanner> version_added: legacy ... iirc 16:43:32 <dag> jtanner: no mattclay told me it should just be merged 16:43:49 <jtanner> oh 16:44:08 <dag> he always signs off on these things 16:44:09 <dag> https://github.com/ansible/ansible/pull/25140#issuecomment-311494205 16:44:31 <jtanner> merged 16:44:39 <dag> so here we come back to my biggest ansibot complaint, nobody reads the whole history because of old CI errors (noise) messing with the real content (signal) 16:44:54 <dag> ansibot is lowering the signal-to-noise ratio 16:45:09 <dag> it does not help the review process, and it does not help stuff to be merged quicker 16:45:18 <jtanner> i don't want to delete those messages 16:45:25 <dag> (especially not when you actually need CI for testing stuff you cannot test beforehand) 16:45:27 <jtanner> i may be willing to turn them into invisible comments 16:45:32 <jtanner> <!--- --> 16:45:50 <dag> yeah, you told me, but people miss the real information (because of old CI issues) 16:46:00 <dag> and that's worse IMO 16:46:04 <jtanner> the bot has no facility for editing/deleting old comments right now 16:46:29 <jtanner> it would not be a quick implementation 16:46:31 <dag> I understand, but that feature request was denied (to add it) as denied, so it wilml never get that :-) 16:47:08 <jtanner> if anything, that test should get "smarter" 16:47:29 <dag> anyway, some of the things that PR was supposed to do was already done in other PRs (talking about waste of existing resources there) 16:47:31 <akasurde> also we need more reviewers 16:47:41 <jtanner> as a busy person, i don't want to have to keep a mental map of what tests can be ignored 16:48:24 <akasurde> #link https://github.com/ansible/ansible/pull/25143 16:48:32 <akasurde> jtanner, thanks for merge 16:49:36 <jtanner> 25143 merged 16:49:40 <dag> jtanner: agreed 16:49:57 <dag> we're on a roll :-D 16:50:02 <akasurde> jtanner, thanks 16:50:04 * jtanner has hope that vcsim will support license soon 16:50:18 <dag> PR 27005 needs integration tests, I was planning to do that before this meeting, but alas 16:50:44 <akasurde> dag, it needs rebase too 16:51:10 <akasurde> dag, are you planning to address my review requests ? 16:51:22 <dag> akasurde: not again :-( 16:51:41 <dag> akasurde: I didn't see the review requests :-( 16:51:53 <jtanner> that's why i don't like touching changelog in PRs 16:51:53 <akasurde> dag, ah 16:52:00 <dag> akasurde: probably because when I got out of vacancies new CI tests added new errors 16:52:24 <akasurde> yup and also some refactor thingy 16:52:27 <dag> jtanner: I don't mind if we make that a rule (although it's nice for others to see what's coming in the next release) 16:52:48 <pdellaert> dag, jtanner - i suggest having changelog changes in a separate PR 16:52:50 <dag> vacancies ? I meant vacation :) 16:52:55 <jtanner> we have ways of figuring out what modules are missing from the changelog 16:53:01 <pdellaert> after the main PR is merged 16:53:22 <jtanner> https://github.com/jctanner/ansible-tools/blob/master/modules_changelog.py 16:53:22 <dag> pdellaert: if that PR takes ages to get merged, the same hell IMO 16:53:27 <pdellaert> same for BOTMETA 16:53:34 <dag> pdellaert: the real issue here is that PRs stay open for months 16:53:53 <pdellaert> dag: in my (one) experience, the changelog/BOTMETA PR was merged an hour or 2 after i created it 16:53:56 <jtanner> botmeta shouldn't need update, if "authors" is filled out properly in the module 16:54:11 <dag> jtanner: is that active ? nice ! 16:54:25 <jtanner> was part of botmeta implementation 16:54:39 <pdellaert> jtanner: ah, i was informed by someone i had to :), good to hear 16:54:39 <jtanner> allowed the initial file to be much smaller 16:54:56 <akasurde> #link https://github.com/ansible/ansible/pull/27236 16:55:02 <dag> pdellaert: it was needed when we had MAINTAINERS.txt 16:55:23 <jtanner> yep, things are a bit different now 16:55:26 <jtanner> easier to keep track of 16:55:40 <pdellaert> akasurde: just want to know if there's anything that needs to happen on 27236 16:55:50 <jtanner> is 27236 a fact module? 16:55:57 <jtanner> oh, a wait_for? 16:56:07 <pdellaert> no, it is a module to wait for the vmware tools to become available 16:56:16 <akasurde> pdellaert, I am OK with PR 27236 16:56:23 <pdellaert> main use casE: wait until a command can be pushed through the tools 16:56:25 <jtanner> nah ... 16:56:41 <jtanner> if it's primary goal is to wait for something, it should have "wait" in the name ... imo 16:56:54 <pdellaert> yeah, but the goal is to expand with tools installation 16:56:58 <pdellaert> (trigger it) 16:57:29 <dag> pdellaert: the examples still call it vmware_guest_tools_wait BTW 16:57:35 <jtanner> well, i'll only say that this is a topic the working group needs to deliberate and hopefully vote on 16:57:44 <pdellaert> oh, dag thanks, i'll update 16:57:57 <pdellaert> sure, and i can always rename/refactor of course :) 16:58:26 <jtanner> you can have module that does lots of things and users need to read the docstrings to understand fully, or you can have separate modules with less guessing 16:58:55 <dag> pdellaert: I would also separate it into two modules, one for installing/updating vmware-tools, and one for waiting 16:59:34 <dag> pdellaert: I wonder if the waiting could be done with a loop over vmware facts instead 16:59:58 <dag> that way people can wait for anything actually, not just the availability (or the availability of a specific version) of vmware_guest tools 17:00:12 <pdellaert> dag, potentially yes, but that would require more work in the playbook itself? 17:00:28 <dag> pdellaert: true, but also a lot more versatile solution 17:01:03 <dag> pdellaert: it would be one of the examples of such facts module, and could be part of the VMware-specific documentation we could add 17:01:33 <akasurde> Can we move on to https://github.com/ansible/community/issues/206#issuecomment-318256386 17:01:36 <akasurde> ? 17:01:37 <pdellaert> why not offer both? A simple solution for something that is a typical use case (sending commands over vmware tools), and provide examples for facts to wait for other stuff? 17:01:45 <pdellaert> akasurde: i need to know what to do :) 17:02:05 <akasurde> pdellaert, Ok 17:02:15 <dag> pdellaert: I'll let others decide, I stated my view ;-) 17:02:26 <jtanner> gonna have to be democratic 17:02:45 <pdellaert> i'm ok with rename, i do think the module still has purpose 17:02:52 <akasurde> I am OK with two separate module - as it is more managable and robust 17:03:05 <jtanner> yes, module definitely has purpose ... i think we all agree on that 17:03:32 <akasurde> #action pdellaert rename module in 27236 17:03:37 <pdellaert> ok, so rename it it, `vmware_tools_wait` to keep it simple? 17:04:25 <jtanner> it's long, but ... vmware_guest_tools_wait 17:04:28 <jtanner> is my vote 17:05:03 <akasurde> +1 for vmware_guest_tools_wait 17:05:07 <pdellaert> ok, done 17:05:10 <pdellaert> thanks! 17:05:19 <pdellaert> (well, done as in decided ;)) 17:06:39 <akasurde> #link https://github.com/ansible/ansible/pull/25944 17:08:01 <jtanner> people ignoring bot message about template =( 17:08:02 <pdellaert> There is something wrong, ha-datacenter only works for the ESXi host, while the username is administrator@vsphere.local, which is vCenter based 17:08:23 <jtanner> we're at the top of the hour, so we should end the meeting before starting a new PR 17:08:53 <jtanner> don't have to though 17:09:12 <jtanner> i need to go eat before 2pm est meeting 17:09:19 <pdellaert> i'll add my comment as a review 17:10:05 <pdellaert> jtanner: what is the right way to define author so that BOTMETA picks it up? Is it github handle? 17:10:32 <jtanner> one sec, i'll look at code 17:10:51 <pdellaert> thx 17:11:16 <jtanner> https://github.com/ansible/ansibullbot/blob/master/ansibullbot/utils/moduletools.py#L588 17:11:26 <dag> Name (@handle) 17:11:44 <akasurde> pdellaert, dag should we close and continue in the next meeting ? 17:12:07 <dag> jtanner: why isn't that processed as yaml ? ;-) 17:12:21 <jtanner> it isn't? 17:12:38 <dag> akasurde: I don't mind stretching it a bit if we can get some more things nublocked 17:12:45 <pdellaert> akasurde: same 17:12:49 <jtanner> the data is sent to yaml.load 17:12:57 <akasurde> ok 17:13:24 <dag> ah, a lot lower than I expected 17:13:33 <jtanner> pdellaert: this should be a valid example https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/vmware/vmware_guest.py#L25-L27 17:13:34 <dag> I saw a lot of data-mangling 17:13:55 <dag> jtanner: so the question has to be, why the data-mangling to only pass the author-lines ? :) 17:14:00 <jtanner> yes, datamanagling is a an unfortunate necessity for what most of the bot has to do 17:14:21 <jtanner> dag: what is the alternative? 17:14:39 <dag> can't you just give it the whole documentation-string, and just get author out of it ? 17:14:41 <jtanner> i can't just put the whole .py into yaml.load 17:14:56 <jtanner> the datamangling is looking for the docstrings 17:15:08 <dag> no, true, but import the module and get DOCUMENTATION ? 17:15:20 <dag> isn't that the purpose for putting it in a variable ? 17:15:41 <jtanner> that would be a lot of importing for a long running process 17:15:42 <dag> (if you don't have time for this now, just tell me ;-)) 17:15:50 <dag> ah, ok 17:15:54 <pdellaert> can we continue with the PRs? ;) 17:15:56 <jtanner> if it were sandboxed, maybe 17:16:04 <dag> pdellaert: sure 17:16:08 <pdellaert> thx for the example, jtanner :) 17:16:09 <akasurde> https://github.com/ansible/ansible/pull/25857 17:16:10 * jtanner has to relocate ... bbiaf 17:16:22 <akasurde> #link https://github.com/ansible/ansible/pull/25857 17:16:29 <dag> pdellaert: you asked the question that got use sidetracked :-p 17:16:38 <pdellaert> dag, not that it's not interesting, just want to continue the meeting ;) 17:16:50 <pdellaert> dag: sure, i'll take the blame! I'm used to that :D 17:17:23 <dag> akasurde: I see a few things I would do differently, but unrelated to the patch 17:17:36 <akasurde> dag, shoot 17:17:48 <dag> (description needs a trailing dot, required=False is unwanted, etc.) 17:17:58 <dag> the usual cosmetic stuff 17:18:09 <dag> author should be a list 17:18:11 <akasurde> dag, I am planning for new PR (let us get this one merged first) 17:18:25 <dag> sure 17:18:33 <dag> ah, it's yours ! 17:18:57 <akasurde> #action akasurde file PR for cosmetic changes in vmware_vswitch 17:19:22 <akasurde> dag, I am also maintainer of this module :) 17:19:52 <dag> I don't have the time to test it myself (with v2.4 around the corner and plenty of PRs I have to maintain because they don't get merged :-/) 17:20:42 <pdellaert> can't test, but looks ok to me 17:22:07 <akasurde> OK anything else on my side to do 17:22:33 <dag> version_added needs to be a string 17:23:07 <dag> you don't have to do any special handling for string vs list 17:23:24 <dag> since you set it to be a list from the argument_spec, it will always be a list 17:23:36 <dag> (if someone puts a string there, it will be converted into a one-item list) 17:23:46 <dag> so actually, the change is even smaller 17:24:02 <dag> (remove the square brackets) 17:25:06 <akasurde> dag, ok 17:25:10 <dag> I would also rename that parameter from 'nic_name' to 'nics' (and keep the alias) 17:25:43 <akasurde> noted 17:25:52 <dag> and personally I would use 'switch' instead of 'switch_name', but that's not that important 17:26:14 <akasurde> can add as alias though 17:26:34 <dag> that's just personal preference (or consistency throughout Ansible) 17:26:49 <dag> but Ansible is not very consistent, that ship has sailed a long time ago :p 17:27:14 <dag> it would be nice to have at least consistency for the vmware modules 17:27:19 <dag> I think that is more important 17:27:26 <dag> (we are doing the same thing for Windows modules BTW) 17:27:43 <akasurde> ok 17:27:47 <dag> you often see things like user_name vs user vs username :-/ 17:28:24 <dag> can we do some more PRs ? 17:29:28 <dag> akasurde: we can always do a VMware sprint, which is basically what we are doing, but maybe we a more focused scope, and issue/PR owners are invited 17:29:59 <dag> (if you wonder why my sentences are missing stuff, I only slept 3 hours) 17:30:02 <akasurde> sure, sounds interesting 17:30:23 <akasurde> dag, np, got the sense of sentence 17:30:31 <dag> it can help to get more people involved (because we involve the issue/PR owners, and we ask other contributors to join) 17:30:47 <pdellaert> sounds like a good plan, indeed 17:31:05 <dag> for Windows we looked at the modules with the most issues, made a list and gets those reviewed 17:31:34 <akasurde> dag, link please ? 17:31:48 <dag> we're focusing on issues here, because we want those to get fixed before looking at the open PRs 17:31:49 <dag> https://github.com/ansible/community/wiki/Windows%3A-sprints#sprint-1 17:32:20 <dag> you can see that most of them got resolved,not always immediately, but the additional attention caused some extra effort afterwards 17:32:44 <dag> and by working per-module, some of the context is already there, so it becomes easier to refactor things and fix more than one issue in the same effort 17:33:10 <dag> (it becomes clear when an approach, or implementation was in need of an overhaul) 17:33:28 <akasurde> Cool 17:33:50 <dag> for vmware the number of open tickets is still manageable 17:33:54 <akasurde> dag, can you please add same page for vmware ? 17:33:59 <dag> sure 17:34:12 <akasurde> #action dag Add sprint page for VMware efforts 17:34:25 <dag> we also picked the modules that were easy to test ourselves (not requiring specific infrastructure) 17:35:26 <dag> the original idea was that we would do that stuff in parallel, but it proved more valuable (and enjoyable) to do it together 17:35:41 <dag> especially since some of the stuff requires a discussion or decision 17:35:48 <akasurde> ok 17:36:04 <dag> so do we want to do some more PRs ? 17:36:20 <dag> or do we want to discuss e.g. what to do by v2.4 ? 17:36:41 <dag> I saw the meeting minutes, but that basically said "let's stick to the plan" 17:36:45 <pdellaert> do we still have much time to do more? 17:36:46 <akasurde> I am Ok for some more PRs maybe 2 or 3 17:37:09 <dag> but the question I wanted to ask was, do we want to add stuff to the plan :-) 17:37:19 <dag> things that have more merit than other stuff 17:37:29 <dag> like adding integration tests, or better coverage support 17:37:40 <akasurde> dag we have enough for 2.4 17:37:43 <dag> rather than adding more stuff, make the existing stuff better 17:38:03 <akasurde> yes, lets make exisiting stuff more better 17:38:07 <dag> akasurde: the idea is not "with the resources we have" but "how can we find more resources" 17:38:25 <jtanner> welcome to my life =) 17:38:30 <dag> if you make a project and add focus, new outside people can start working on it 17:38:51 <jtanner> that's why i prioritize bot work 17:38:57 <jtanner> make the spice flow 17:39:01 <dag> for Windows we are seeing improvement and acceleration, albeit not as much as I had hoped 17:39:09 <dag> jtanner: yes, that's important 17:40:06 <dag> akasurde: a lot of people have joined the VMware WG after I asked who wanted to join 17:40:25 <akasurde> dag, yes indeed 17:40:27 <dag> akasurde: and those people are currently not activated (while they did spoke out the wish to become more involved) 17:40:46 <dag> so I think we are missing out on a real opportunity 17:40:56 <dag> (for Windows, nobody signed up :p) 17:41:05 <jtanner> can you blame them 17:41:06 <jtanner> =P 17:41:09 <dag> the difference could not be bigger 17:41:24 <pdellaert> ;) 17:41:34 <dag> the exact same message, to the same people (prior contributors, existing PR owners) 17:41:57 <dag> and there were 3x more Windows people than VMware people 17:42:12 <dag> anyway, how can we activate them ? 17:42:20 <akasurde> what is situation now 17:42:23 <jtanner> finding more volunteers/maintainers is a larger problem for the entirety of the ansible project 17:42:37 <jtanner> it's an issue we haven't solved 17:42:42 <dag> ask for reviews would be a simple request, but I am afraid that may not trigger people 17:43:10 <dag> maybe the sprints could work here better 17:43:31 <akasurde> Do you think the time is the issue ? 17:43:35 <dag> and merge things while we're doing it 17:43:44 <jtanner> finding people who know vmware, know the soap api, know pyvmomi, know ansible, know how to dev ansible is a difficult set of qualities to find 17:43:56 <dag> akasurde: I think most people wonder what they're contribution could be 17:44:03 <dag> their 17:44:13 <akasurde> ah 17:44:19 <jtanner> again, a problem for all of ansible 17:45:03 <dag> and I think the solution is to get them into it step-by-step (so a sprint, or making integration tests together) 17:45:42 <jtanner> that's what i started with filament 17:45:53 <jtanner> or tried 17:45:58 <dag> jtanner: the question is if we need all SOAP api/pyvmomi experts, for testing modules we don't 17:46:03 <pdellaert> and, as jtanner says, in case of vmware, finding the combination is not easy. However, of one or two are missing, they could learn those 17:46:21 <dag> the people that signed up at least are interested 17:46:39 <dag> either to be in the loop (notified) or to contribute (because they depend on it) 17:46:53 <jtanner> they can learn the ansible side via https://tannerjc.net/wiki/index.php?title=Ansible_Developer_Filament 17:47:41 <dag> jtanner: right, but that's already a big scary commitment 17:48:01 <dag> jtanner: if you look at that, you think "a few hours work" and you do something else 17:48:16 <jtanner> *shrug* ... i they can't do level 1 from that, they're probably not ready for python development 17:48:25 <dag> hehe 17:48:55 <dag> maybe I look at it from a different point of view 17:49:04 <dag> I don't think they all of have to be jtanner's 17:49:08 <dag> I am not a jtanner 17:49:14 <jtanner> i'm not a dag 17:49:27 <dag> :-) 17:49:55 <dag> you answered so quick, I am actually wondering if you're scripted :) 17:50:12 <dag> ok, let's do some PRs now 17:50:21 <dag> and I'll see if we can prepare a sprint 17:50:41 <dag> the whole feel-good story behind sprints are here: https://github.com/ansible/community/blob/master/SPRINTS.md 17:52:27 <akasurde> #link https://github.com/ansible/ansible/pull/26323 17:54:50 <jtanner> dag: i might be a script ... that would be the ultimate career goal for people like us, right? 17:55:11 <akasurde> ansibot == jtanner 17:55:15 <akasurde> hehe 17:55:30 <jtanner> i LOVE to label 17:55:40 <dag> akasure: I would change the logic a bit 17:55:43 <akasurde> I am sure jtanner is a script now 17:56:07 <akasurde> AI maybe 17:56:21 <dag> akasurde: I would set sslContext to None by default, change it if 'not validate_certs', and call SmartConnect only once 17:56:35 <dag> that simplifies the code a bit, since sslContext is None by default if not specified 17:57:08 <dag> then you can add the try/except directly around the SmartConnect line, so that's preferred as well 17:57:20 <akasurde> dag, OK, I don't remember why kept it apart 17:58:26 <dag> there's still the issue with the second SmartConnect call in the except block, that could be improved I guess (since an new exception will cause an improper module failure) 17:59:17 <akasurde> there is no smartconnect in except block 17:59:20 <dag> ah, sorry 17:59:23 <dag> you already removed it 17:59:25 <dag> damned :) 17:59:33 <akasurde> dag you need sleep 17:59:40 <dag> so that's perfect ! 18:00:03 <dag> yeah, and tonight another all-nighter (Pacific Time) 18:00:36 <dag> personally I would catch all the various exception as 'e' 18:00:43 <dag> and use 'e' in all the messages 18:01:24 <dag> I don't see a good reason to have unique exception names in an exception-cascade (I find it more confusing even) 18:01:46 <akasurde> ok 18:02:57 <dag> akasurde; if you do it now, we can merge it ! 18:03:20 <akasurde> just sslContext, right ? 18:06:14 <dag> yeah, so: 18:06:15 <dag> sslContext = None 18:06:15 <dag> if not validate_certs: 18:06:15 <dag> sslContext = ... 18:06:15 <dag> try: 18:06:15 <dag> service_instance = connect.SmartConnect(..., sslContext=sslContext) 18:06:15 <dag> except SomeException as e: 18:06:16 <dag> module.fail_json(... % e) 18:06:16 <dag> except AnotherException as e: 18:06:17 <dag> module.fail_json(... % e) 18:06:37 <dag> sorry, that was ssl_context 18:07:05 <akasurde> ok 18:07:34 <dag> I am also wondering why we have that apierror result value 18:07:44 <dag> I would prefer we add the error to the msg-string 18:08:01 <dag> otherwise different error messages look exactly the same without the additional context 18:08:30 <akasurde> ok 18:08:31 <dag> and apierror is not something people would want to check for anyhow, so there's no real benefit of having another custom error-marker in the output 18:09:43 <dag> and then you don't have to add the error_msg string at the top, just repeat it twice with %s in it 18:09:56 <dag> I always prefer to have the error-string at the location where it is raised 18:10:31 <dag> so you can easily grep for it (and if it is in the code more than once, you can tell straight away) 18:11:00 <akasurde> dag, have a look 18:11:06 <dag> we're not optimizing for memory efficiency (or at least leave that up to the compiler ;-)) 18:11:46 <dag> yup, I would move the error_msg directly into module.fail_json() though 18:12:23 <dag> even if it is the same string (but it doesn't have to be the same string, you could actually indicate a connection error, or an invalid login error in that message 18:12:44 <dag> Unable to connect is very broad, especially if we now the login was invalid 18:12:54 <akasurde> ok 18:13:23 <akasurde> I will close the meeting and then we can take the discussion to ansible-vmware, OK ? 18:13:23 <dag> So "Failed to login to vCenter or ESXi API. %s" % e.msg 18:13:33 <dag> yeah :-) 18:13:48 <dag> BTW we could have a bot in ansible-vmware and do meetings there 18:14:03 <dag> we don't have to, but it does make it easier to list the meeting logs/minutes by channel 18:14:21 <bcoca> bot has resource limits that is why we dont have it on all channels 18:14:26 <dag> and people only interested in vmware are automatically involved 18:14:33 <dag> bcoca: the resource limits have been lifted 18:14:43 <akasurde> #endmeeting