16:01:03 <Qalthos> #startmeeting Ansible Network Working Group
16:01:03 <zodbot> Meeting started Wed Jun 12 16:01:03 2019 UTC.
16:01:03 <zodbot> This meeting is logged and archived in a public location.
16:01:03 <zodbot> The chair is Qalthos. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:03 <zodbot> The meeting name has been set to 'ansible_network_working_group'
16:01:40 <Qalthos> #chair ganeshrn ikhan privateip trishnag pabelanger dmellado
16:01:40 <zodbot> Current chairs: Qalthos dmellado ganeshrn ikhan pabelanger privateip trishnag
16:02:15 <Qalthos> #link https://github.com/ansible/community/labels/network is where the agenda for this meeting can always be found
16:02:21 * ganeshrn waves
16:02:24 <Qalthos> #topic Core Updates
16:03:18 <Qalthos> #info Ansible 2.8.1 should be coming very soon now
16:03:54 <Qalthos> After which, 2.9 planning should start to formalize
16:05:15 <Qalthos> The 2.9 roadmap dates are in the git repository, but I can't seem to find them on docs
16:05:38 <Qalthos> It should eventually live at https://docs.ansible.com/ansible/latest/roadmap/ROADMAP_2_9.html
16:06:45 <Qalthos> Let's get in to the agenda, then
16:06:58 <Qalthos> #topic Meraki PRs
16:07:28 <mrproper> Good morning/afternoon. Lets start with https://github.com/ansible/ansible/pull/53891 which you commented on a few minutes ago. I responded to the comment.
16:08:14 <Qalthos> I'm not seeing any response there?
16:08:26 <mrproper> Ugh there's a conflict too,
16:09:10 <mrproper> Yeah I don't know where the comment went. I'll add the comment.
16:10:08 <mrproper> Reload please.
16:12:40 <Qalthos> That's not really answering my question. You've commented out a fail_json(), but have code doing something similar immediately after it.
16:12:50 <Qalthos> Why is the fail_josn still there, commented?
16:13:23 <mrproper> Debugging during development. I can remove that as well.
16:13:55 <Qalthos> Alright, that and fixing the conflict should be fine, then
16:13:56 <mrproper> It really came down to I wanted the whole playbook to fail during development instead of continuing on.
16:14:06 <mrproper> I'll @ you on the PR when I've made the changes?
16:14:11 <Qalthos> mrproper: sure
16:14:19 <mrproper> Next is https://github.com/ansible/ansible/pull/57289 which is a new module.
16:15:04 <Qalthos> As for the new module that's left, I haven't had a chance to go through that (or any of the new modules on the agenda) yet
16:15:20 <mrproper> Understood. I figured those take more time than patches.
16:15:28 <Qalthos> mrproper: Anything in particular you want to mention about it?
16:15:46 <mrproper> No. It should be a relatively straight forward one, at least in my mind.
16:16:44 <Qalthos> Alright, I should be going through them later today. You seem pretty on top of your PRs, so I'm sure you'll know if I have any concerns.
16:17:06 <mrproper> Thank you! Let me know if something jumps out.
16:17:12 <mrproper> I'm through with Meraki topics for this week then.
16:17:36 <Qalthos> mrproper: thanks
16:18:22 <Qalthos> #topic Avi PRs
16:18:53 <Qalthos> chaitanyaavi: I see there's an update on 57531
16:19:51 <chaitanyaavi> Yes I have updated both the PRs and @grastogi have replied on your comments as well
16:27:38 <Qalthos> Regarding 57116... there's a lot going on in there that seems unnecessarily tied to the specifics of the API
16:29:28 <Qalthos> Determining that isn't helped when there is only one example, but in particular the parameters specified as paths when it seems they could be specified just as well as strings which are built in to paths in the module
16:30:19 <grastogi> is core of the debate about using syntax like "/api/tenant?name=admin"?
16:30:37 <Qalthos> grastogi: That is a lot of it
16:32:48 <grastogi> Yes, having that syntax has allowed us to properly check against the reference. In a way your argument is that name should be enough for matching the reference. However, having it this way allowed us to pass hints to the module about type of the reference. This we used to then create a generic implementation to match against what is returned from the Avi controller and not having to pass UUIDs in the playbooks.
16:32:48 <grastogi> 
16:34:11 <grastogi> yes, there is a path but that is mostly a reference and always in the format of /api/<obj_type>?name=<obj_name>
16:35:59 <Qalthos> Then surely the module could accept a name as a parameter and send the formatted path to the generic implementation
16:36:13 <Qalthos> or a dictionary of name and type if name alone is insufficient
16:36:56 <Qalthos> The user should not have to know or care how the paths are formatted, that is the point I am trying to make
16:39:22 <grastogi> yes, I completely agree with you. It was not our best option. We could not achieve the solution with just name. The other one is not as clean so didn't implement that. User does need to know the type of object as you can't put a name and not know whether it is a virtualservice or pool or tenant
16:41:17 <grastogi> still it is a bit ugly. we will honestly revisit if we can find a solution. However, customers are already using this in production. So, would request not hold the PR for just this ready
16:41:20 <grastogi> sorry reason
16:41:34 <Qalthos> In that case, I would suggest adding suboptions to each of those parameters, which should allow you to be more explicit about what sorts of values are expected or appropriate
16:42:01 <Qalthos> This is not going to get merged in its present condition
16:42:10 <grastogi> yes, we are already discussing use of suboptions more pervasively in our modules. thanks for bringing it up in the other PR
16:44:12 <Qalthos> I'll copy the relevant bits of this discussion back to the PR, just so it doesn't get lost
16:44:57 <Qalthos> grastogi: Anything else before we move on?
16:45:09 <Qalthos> chaitanyaavi: ^?
16:45:11 <grastogi> Again, this is already in use in production. It is also consistent with other Avi modules. So, still request we don't hold this up while we look for solutions.
16:47:58 <Qalthos> grastogi: I do apologise for the inconsistent application of this rule in the past, things do occasionally get lost. However, it seems to me that we have a solution, which should be more robust and expressive than passing paths around
16:49:41 <Qalthos> And as-is, this does not meet the standards for inclusion that we try to keep to, for the reasons already discussed.
16:52:11 <Qalthos> So unless there is something else, I am going to move on.
16:53:57 <Qalthos> #topic CloudEngine
16:54:52 <Qalthos> xuxiaowei0512: As I mentioned before, I haven't had a chance to look at new module PRs yet
16:55:11 <xuxiaowei0512> Ok , I got it
16:58:46 <Qalthos> The other PRs seem fine, I think they have all been merged now
16:59:37 <Qalthos> xuxiaowei0512: If that doesn't seem correct, then let me know what I am missing, otherwise, I'm going to close the meeting
17:00:25 <xuxiaowei0512_> I also have updated PR  57264.
17:00:44 <xuxiaowei0512_> How about PR 57264?
17:01:15 <Qalthos> Ah, that one failed to merge, let me try again
17:01:26 <Qalthos> GitHub can be slow sometimes
17:02:15 <xuxiaowei0512_> Thanks.
17:02:46 <Qalthos> Alright, thanks everyone for coming
17:02:50 <Qalthos> #endmeeting