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