18:01:41 #startmeeting networking_policy 18:01:42 Meeting started Thu Aug 9 18:01:41 2018 UTC and is due to finish in 60 minutes. The chair is tbachman. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:45 The meeting name has been set to 'networking_policy' 18:01:51 Hi 18:01:52 #topic Agenda 18:02:20 I don’t really have one — but if anyone has topics that they want covered, go ahead and shout them out 18:03:47 If annakk were here, I’d suggest updating her on the queens support work 18:04:15 ack 18:04:20 * tbachman peeks around fo annakk 18:06:58 tbachman: the issue that kent is seeing might be related to neutron UT setup (perhaps changed in queens) 18:07:17 SumitNaiksatam: that’s a good topic :) 18:07:32 #topic queens branch 18:07:49 We’re workng on adding queens to our stable/branches 18:08:20 #link https://review.openstack.org/#/c/581911/ <== current queens WIP patch 18:08:33 more precisely, towards basing our master on neutron’s stable/queens instead of stable/pike 18:08:47 rkukura: thx! 18:09:05 actually both, right? 18:09:19 SumitNaiksatam mentioned that some of the UT failures might be related to the neutron UT setup, which may have changed in queens 18:09:25 SumitNaiksatam: do you have additional insight on that? 18:10:20 tbachman: not really, thats my conspiracy theory for now :-) 18:10:25 heh 18:10:39 was discussing with kent a couple of days back, and looked at it briefly 18:10:43 If it’s true, then it’s just a conspiracy ;) 18:11:14 tbachman: and we have had a long history of those :-P 18:11:22 lol 18:11:45 i couldnt nail it down, but the stack trace seemed to suggest that to me 18:11:53 I know that some of the UT failures seemed to suggest that API calls were being made more than once 18:12:04 or somehow became recursive 18:12:07 it doesnt seem like its hitting any of our code where it fails 18:12:43 yeah, moreover that recursive thingy is with regards to neutron resources 18:12:57 interesting 18:13:12 pecan.middleware.recursive.RecursionLoop: Forwarding loop detected; '/error/404' visited twice (internal redirect path: [u'/networks/943de9b6-6136-4f22-8f86-9324ac0b0074.json', '/error/404']) 18:13:31 i have never seen this error before 18:14:40 I think in queens they moved to the pecan middleware? 18:15:36 oh 18:15:43 this is in the test code — not even our plugin 18:15:45 i see 18:16:04 Did we do any special wrapping of the requests? 18:16:12 for UTs? 18:16:34 nothing that comes to me immediately 18:17:00 we might have inadvertantly done something and that might have come into play with the move to pecan 18:17:10 i think the pecan migration was ongoing for a long time 18:17:14 https://github.com/jimrollenhagen/pecan/blame/master/pecan/middleware/recursive.py 18:17:40 actually #link https://github.com/jimrollenhagen/pecan/blame/master/pecan/middleware/recursive.py#L28-L30 18:17:45 it seems to have been there for a while 18:18:14 so i dont think its a change in pecan 18:18:46 annakk just emailed — I guess she’s having trouble joining. I think it’s probably b/c of the registered NIC requirement that the infra folks imposed to deal with all the spam on IRC 18:19:16 tbachman: good point, i noticed her email too, but it didnt strike me that would have been the issue 18:19:24 good catch 18:20:00 Did queens change the default to pecan? Have we ever tested using pecan with earlier releases? 18:20:03 i think rkukura might be more familiar with the changes to the neutron UT setup 18:20:27 I’ve only been looking at neutron branches supported by gbp! 18:20:28 rkukura: my understanding was that the change was incrementally happening 18:20:34 has been happening 18:21:13 now if you ask me what that incremental path was, i wont be able to tell, but pecan was definitely in plan in pike too 18:21:18 I thought there was a switchover in neutron for queens tho 18:21:21 plan -> play 18:21:23 meaning the servers were switch 18:21:25 switched 18:21:33 the code was there before, but you had to configure to select it 18:21:38 but I think in queens it’s the defaulit 18:21:44 I’d think pecan support would have been usable for at least a cycle before becoming the default 18:21:54 tbachman: okay, that might be the case 18:22:40 also, i think pecan libraries were being used earlier (which is what i might be recalling having hit before) 18:22:53 anyway 18:23:16 https://github.com/openstack/neutron/blob/stable/queens/neutron/api/v2/router.py 18:23:24 annakk: hi 18:23:28 https://github.com/openstack/neutron/commit/db1058a499353149a9e57d8c1d7e8e64b30772f9#diff-b9672caf8662b545dab77591f4fa326c 18:23:33 hi annakk! 18:23:36 hi! 18:23:41 hi annakk! 18:23:52 sorry took me some time to figure out the verification 18:24:15 #link https://github.com/openstack/neutron/commit/db1058a499353149a9e57d8c1d7e8e64b30772f9#diff-b9672caf8662b545dab77591f4fa326c <= switch to pecan for UTs 18:24:19 tbachman: good find 18:24:21 that was in queens, I believe 18:24:38 I’d stumbled upon this before, but I can’t recall why 18:24:49 that’s how I usually find things :P 18:25:04 :-) 18:25:32 annakk: just to catch you up — we’re discussing a WIP patch for adding stable/queens, and moving master to queens 18:26:00 Here’s the patch (already linked for IRC, so won’t re-link again): https://review.openstack.org/#/c/581911/ 18:26:05 yes thanks for the update 18:26:09 np! 18:26:18 this switch should have been ideally transparent to us 18:26:20 We were just discussing some of the UT failures 18:26:22 SumitNaiksatam: ack 18:26:42 but perhaps we are using some aspect of the old APIRouter (or using incorrectly) 18:26:44 thinking loud 18:28:03 is it possible that our gbp REST API methods calling neutron’s REST API is being detected as recursion? 18:28:30 I’ll admit I haven’t looked closely at recent versions of the WIP patch, or at the failures 18:28:51 rkukura: I was wondering the same 18:29:20 since we have that extra layer that was in place in case GBP ever became an endpoint 18:30:27 I guess we’ll dive into this some more with the patch 18:30:33 annakk: anything you wanted to discuss? 18:30:38 it’s been some time since we met 18:31:08 we should probably also mention recent changes to the core team 18:31:50 rkukura: yes, although I don’t know if we’ve spoken directly with them about this? 18:31:51 rkukura: thats a good theory 18:32:03 but i dont think we go through the API layer for those calls 18:32:31 not really 18:33:36 don’t recall if we call the plugin methods directly, or go through some neutron code 18:33:57 #link https://github.com/openstack/group-based-policy/blob/master/gbpservice/network/neutronv2/local_api.py#L288 18:34:21 i might be forgetting things here, but i think that is a direct call on the plugin reference 18:35:08 SumitNaiksatam: That does look pretty direct 18:35:47 so, maybe not the change to pecan then 18:36:03 or at least not in-and-of-itself 18:36:08 secondary effect somehoe 18:36:11 somehow 18:37:01 rkukura: but i have to say again, thats a really smart theory! (given that the message says “twice”) :-) 18:37:12 I guess we should move on 18:37:24 #topic Team Cores 18:37:37 To address rkukura’s comment directly: two cores — who are also people from our team — have recently moved on: Ivar Lazarro and Amit Bose. I don’t believe that they are going to continue participating in GBP, but we do have to follow up with them to confirm. 18:38:25 SumitNaiksatam: annakk: rkukura: putting out there whether or not we should consider adding cores to GBP 18:38:49 i would proposing adding Kent Wu 18:38:57 +2 18:39:02 i think rkukura also suggested this before 18:39:06 +2 18:39:09 +2 18:39:11 okay 18:39:28 I’m not sure if there’s an official process here for adding cores 18:39:31 kent has been pretty active 18:39:35 ack 18:39:38 (although more on the driver side) 18:39:53 I think the queens patch qualifies him! 18:39:53 but having worked with him, i know he understands the code base 18:40:04 rkukura: ah good point! 18:42:47 I was trying to look him up on stackalytics, but resulted in a #fail 18:43:05 I think it doesn’t cover GBP 18:43:48 #6 on our committer list 18:43:48 we had it in the past, but not sure if it was dropped at some point 18:44:04 anyway, i think we are all in agreement :-) 18:44:11 #link https://github.com/openstack/group-based-policy/graphs/contributors <= GBP contributors list 18:44:30 #link https://github.com/openstack/group-based-policy/commits?author=kentwu1 <= Kent Wu’s commits in GBP 18:44:39 thanks to ivar and amit for their fantastic contributions 18:44:40 SumitNaiksatam: ack 18:44:44 SumitNaiksatam: ack again 18:45:25 Do we need to do something like pound-startvote? 18:45:27 to make it official? 18:45:45 tbachman: probably not 18:45:49 k 18:45:53 Alright 18:46:05 tbachman: you can just add him to the team group-based-policy team 18:46:11 SumitNaiksatam: will do! 18:46:21 Unless there’s something I’m missing, we’ve just elected Kent Wu as a core in GBP 18:46:25 Congratulations Kent! 18:46:53 rkukura: annakk: SumitNaiksatam: anything else? 18:47:20 hopefullly Kent will start attending these (monthly) meetings 18:47:22 since we're mentioning gratitudes, I wanted to thank Sumit for all his efforts 18:47:33 annakk: +1k! 18:47:49 annakk: thanks annakk :-) 18:47:54 and tbachman 18:48:02 thanks SumitNaiksatam! 18:48:17 rkukura has been an equal partner in crime from the beginning 18:48:19 a really big thanks for being patient with all my questions 18:48:40 annakk: thanks for all your questions, and contributions :) 18:48:41 annakk: that was nothing, dont worry 18:48:48 :) 18:48:49 tbachman: +1 18:49:10 If there’s nothing else, then I’ll close the meeting 18:49:26 nothing from me for today! 18:49:30 tbachman: thanks! 18:49:33 nor from me 18:49:37 SumitNaiksatam: np! 18:50:01 thanks everyone! 18:50:03 #endmeeting