16:00:01 <Qalthos> #startmeeting Ansible Network Working Group
16:00:01 <zodbot> Meeting started Wed Mar 27 16:00:01 2019 UTC.
16:00:01 <zodbot> This meeting is logged and archived in a public location.
16:00:01 <zodbot> The chair is Qalthos. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:01 <zodbot> The meeting name has been set to 'ansible_network_working_group'
16:00:11 <Qalthos> #topic Core Updates
16:00:40 <Qalthos> We're getting close to freeze, so not a lot of updates from the Ansible team
16:01:17 <Qalthos> That said, we are actually further from freeze than we were last week
16:01:38 <Qalthos> #info Community freeze has slipped to 2019-04-04
16:01:55 <Qalthos> #link https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_8.html should always have the latest dates
16:02:35 <Qalthos> So we have a few more days, but please get things in soon if you want them for 2.8!
16:02:48 <Qalthos> Also:
16:03:22 <Qalthos> #info NIOS updates to use `connection: httpapi` instead of `local`
16:03:54 <Qalthos> #info Various bugfixes
16:04:28 <Qalthos> And we're still busy reviewing PRs for 2.8
16:05:02 <Qalthos> #link https://github.com/ansible/community/labels/network is where this meeting's agenda can always be found
16:06:38 <Qalthos> Most everything there is either already done or in active progress, so
16:06:44 <Qalthos> #topic Open Floor
16:07:01 <Qalthos> Anil_Lenovo: I think everything you've asked for is in, correct?
16:07:34 <Anil_Lenovo> I have one more module to go in
16:07:59 <Anil_Lenovo> Which i will be putting in by tomroow
16:08:16 <Anil_Lenovo> I have already made one PR for it few day back
16:09:33 <Anil_Lenovo> cnos_vrf
16:09:57 <Anil_Lenovo> I have done, the coding Functional tests which foud working
16:10:04 <Anil_Lenovo> Now UTs are pending
16:10:48 <Anil_Lenovo> which i will finish by tommorow India time say 3-4 PM and will add on to the PR
16:12:11 <Anil_Lenovo> PR#54188
16:13:19 <Qalthos> Anil_Lenovo: And that's it from you for 2.8?
16:14:28 <Anil_Lenovo> yes.. Thats all. Rest of my work will be in Galaxy..
16:15:16 <Qalthos> Neat
16:15:27 <Qalthos> Anyone else have anything for this meeting?
16:15:37 <UjwalKomarla> I just opened this issue for restconf_config - https://github.com/ansible/ansible/issues/54470
16:17:05 <UjwalKomarla> restconf_config module 'post' method expected on Resource identifier..
16:18:07 <UjwalKomarla> However, according to restconf RFC(8040), target resource for POST method for resource creation is parent of the new resource.
16:21:33 <Qalthos> I'm not entirely following this. Your gist indicates you are trying to run it against the path "openconfig-vlan:vlans"
16:22:36 <UjwalKomarla> My Bad, I pasted the wrong info in 'ACTUAL RESULTS' of issue..
16:22:37 <Qalthos> But the log you provided has you using "openconfig-vlan:vlans/vlan=1500", which should fail
16:22:59 <Qalthos> Ah
16:24:13 <UjwalKomarla> Basically, when I'm trying to create 'vlan=1500', I need to be POSTing on 'openconfig-vlan:vlans/' - which would always exist.
16:24:57 <Qalthos> I'm with you so far
16:25:46 <Qalthos> Is your POST complaining that 'openconfig-vlan:vlans/' already exists?
16:26:48 <UjwalKomarla> In the 'restconf_config' when we use POST method, we are first validating that the resource doesn't exist... By doing a GET on 'openconfig-vlan:vlans/'...
16:27:23 <UjwalKomarla> And the module *fails* with a return of 409, when it sees 'openconfig-vlan:vlans/' exists.
16:29:04 <Qalthos> so you do a restconf_get on 'openconfig-vlan:vlans', verify that no vlan numbered 1500 exists, and then restconf_config with POST to 'openconfig-vlan:vlans' and it complains that the same path already exists?
16:29:09 <Qalthos> Do I have that correctly?
16:30:40 <UjwalKomarla> No, the restconf_config does a restconf.get within the module and checks it receives a 404...
16:31:07 <UjwalKomarla> It doesn't look in the response to see whether, it has vlan 1500 exists or not.
16:32:02 <Qalthos> It gets a 404 on 'openconfig-vlan:vlans'?
16:32:41 <UjwalKomarla> It expects to get a 404, but instead it has a response.
16:34:00 <Qalthos> Why should it expect a 404 to the parent resource? It (as we have already agreed) should always exist.
16:34:23 <Qalthos> Could you please update the issue with the actual results you're getting from the playbook linked in the issue?
16:34:42 <Qalthos> This would probably be a lot easier if we're both talking about the same things
16:35:34 <UjwalKomarla> Just updated..
16:35:58 <smolz> any chance i could get some help with 52892?
16:38:29 <Qalthos> Hmmm
16:38:43 <UjwalKomarla> My guess is that, restconf_config POST was written expecting that the URI would be 'openconfig-vlan:vlans/vlan=1500/' and not 'openconfig-vlan:vlans/'
16:38:55 <UjwalKomarla> Which is how PUT would work..
16:40:15 <Qalthos> UjwalKomarla: Just to cover bases, does a PUT to 'openconfig-vlan:vlans/vlan=1500' work at all?
16:41:12 <UjwalKomarla> EXOS doesn't support PUTs. So, haven't been able to try
16:41:42 <Qalthos> Huh
16:42:27 <UjwalKomarla> Yeah, EXOS supports only POST, PATCH, GET, DELETE
16:42:56 <Qalthos> Well, if the server isn't following the RFC either, this might get troublesome
16:43:15 <UjwalKomarla> When, I said "Which is how PUT would work..", I meant that is how RFC 8040 describes...
16:43:45 <Qalthos> POST should work properly. I can do some digging to get dome examples, and I'll report back on the issue if I find anything
16:44:27 <Qalthos> #action Qalthos report back on restconf_config with method: post
16:44:36 <UjwalKomarla> Thanks
16:44:59 <nilashishc> smolz: Based on the error, I'm guessing you'll need to mock `get_connection`?
16:46:04 <nilashishc> Try adding the following in setUp() -> self.mock_get_connection = patch('ansible.module_utils.network.ios.ios.get_connection')
16:46:04 <nilashishc> self.get_connection = self.mock_get_connection.start()
16:46:20 <Qalthos> (oops, I forgot to update the topic)
16:46:42 <Qalthos> #topic ios_l2_interface voice vlan
16:47:52 <smolz> added and committed
16:48:16 <nilashishc> smolz: Did it pass locally?
16:48:53 <Qalthos> Probably what they actually need is a mocked `run_commands()`, not the connection
16:50:39 <nilashishc> oops I didn't notice `run_commands()` mock was missing
16:50:52 <Qalthos> Mocking the connection seems like a far more troublesome way of going about it
16:53:19 <nilashishc> ```
16:53:31 <nilashishc> Yeah, 2.6 units failed with
16:53:33 <nilashishc> string = <MagicMock name='get_connection().run_commands().__getitem__()' id='63468880'>
16:53:33 <nilashishc> flags = 0
16:53:33 <nilashishc> def search(pattern, string, flags=0):
16:53:33 <nilashishc> """Scan through string looking for a match to the pattern, returning
16:53:34 <nilashishc> a match object, or None if no match was found."""
16:53:34 <nilashishc> >       return _compile(pattern, flags).search(string)
16:53:34 <nilashishc> E       TypeError: expected string or buffer
16:53:35 <nilashishc> /usr/lib/python2.6/re.py:142: TypeError
16:57:20 <smolz> changing it to the run_commands
17:01:08 <smolz> same error
17:04:45 <Qalthos> smolz: Well, you also haven't set anything in load_fixtures for return_commands, so it almost certainly won't work that way
17:04:56 <Qalthos> s/return/run/
17:05:31 <Qalthos> We can keep going through this if you like, but I'm going to close the meeting out, unless anyone has any objections real quick
17:06:28 <Qalthos> #endmeeting